DBASE III error 'field numeric overflow' 2

[bobkat88]

Hi All:

We have been using DBASE III plus (or perhaps it is DBASE IV - its been so long I don't remember) for our video rental database program. The program was written for us in 1993 or 1994 and has been running great until yesterday.

Whenever we try to rent out a movie the program crashes and gives this error message: ---> "Proc PRREPS13 line 1778, field numeric overflow" (quotation marks are mine).

Now we do not have the source code -- the person who wrote the program never gave it to us. Even if I had it my knowledge of database programming is so limited I probably could not fix it anyways...

I seem to have found a corelation between the crashing and the date fields. Our program has both a "Date Rented" field and a "Date Due" field. The program is designed to add 15 days to the "Date Rented" date (which I presume is grabbed from the system date) and generate the "Date Due" date. Now the weird thing is -- if you go back into the program and examine the new rental record that made the program crash, the "Date Due" field is blank -- so the program is not adding the 15 days anymore. The "Date Rented" field does however the current date.

If any of this makes sense I would really like to at least get an idea of what is wrong. Our computer is a 486 DX120 with 32 MB ram running Windows 98.

Many thanks for any and all replies.

bobkat

 

[MiggyD]

Unless the program was written in another language with DBF capability (ex: Clipper) you may have the source code available for modification. You should check to see if you do or not.

-----How-----

1a) Is the program started once the machine is turned on? (START>PROGRAMS>START UP) [or by other means?]

1b) is the program started by clicking on an ICON on the desktop?

--in either case--

2) (Highligh the STARTUP item and then)right-click the ICON and select "Properties"

3) locate the directory/folder that it is to run from

4) open (either) My Computer/Explorer and go to that directory.

5) Are there any [highlight]*.PRG[/highlight] files? (note: this "PRG" is the extenstion (or currently called SORT>'TYPE').

6) if there are any then you can use NOTEPAD to view (and eventually) edit them.

-----/How----

However, from what you say, it sounds like reguluar file corruption (ex: Not Defrag'd recently, Scandisk'd, new *FASTER/Cached* HD, etc.)

check to see if anyone has (ahem) updated/installed new(er) software, too.

Let us know if any of this helps.
--MiggyD

 

[bobkat88]

Hi Miggy:

Thanks for your quick response. There are no .PRG files that I can find. The main program is a .EXE file. All other files are .dbf or .ndx

I'm pretty sure the program was written in dBase III plus as I recall once he can over with the source code on diskette - this was long ago. Why he never gave us the source code I don't know.

The hard drive has been degragged and scanned and no new software has been added lately. Nothing has changed - hardware wise.

Thanks again.

bobkat

 

[tviman]

If you can reindex the database files, do so now. That's about the only thing you can do since the program is compiled.

There's always a better way. The fun is trying to find it!

 

[bobkat88]

Hi tviman:

Well, I have reindexed all databases many times and defragged/scandisked the HD three times all to no avail.

Is there any software out there to "de" compile the program? In other words can we reverse-engineer and retrieve the source code from the executable?

My only other option at this point is to go to another program that uses .dbf files. Any suggestions? How about Microsoft Access? Or is the learning curve too steep? I've got to get this thing going again real quick.

Thanks again.

bobkat

 

[MiggyD]

Is there any software out there to "de" compile the program? In other words can we reverse-engineer and retrieve the source code from the executable?

There are programs that will decomplie an EXE file (but only sofar) -- and then there are legal issues that may arise. If possible, try contacting the author/code writer for help in determining the cause--could be his/her program or maybe the BIOS need to be updated (since you mentioned a 486 system.)

My only other option ... another program that uses .dbf files. ... How about Microsoft Access? Or is the learning curve too steep?

If you have no Access (nor any VBA) background/experience, then the 'learning curve' isn't too steep--it's sheer and vertical.

I'm sure if you use google, yahoo, mamma, or any other web search engine you can find more 'modern' video store software available. Also, make sure to speak with someone in Tech-Support (not customer service reps) and confirm that their progs will be able to use DBF or CSV data (if your current program allows exporting in that manner). Ask the 'service reps' about return policies, should it not meet your requirements.

One of my clients (incidentally a video store owner) has a program call 'video vision'.[sup]*[/sup] It was supposed to be compatiable with the machine he had at the time: Win98SE (0 sp) with 30GB HD and (I think) 125MB ram. Every 2-3 weeks he would call me with a new problem. But after upgrading to Win XP, I no longer got "HELP! ME!"...so make sure you read any fine print--should the store determin a new program is in order.

--Now back to my questions:

'The main program is a .EXE file.'
Q) What is the EXE file's name? Is it DBASE.EXE?

'All other files are .dbf or .ndx'
Q) What other extensions are there (if any)? Any sub directories there?

--MiggyD

[sup]*[/sup] - forgot to mention, this program uses Access tables to store the data.

 

[bobkat88]

If you have no Access (nor any VBA) background/experience, then the 'learning curve' isn't too steep--it's sheer and vertical."

LOL !!! I suspected that...


I doubt that the problem is hardware or BIOS related because the program has been running on the same 486 for years without a hitch; no software changes. The only thing we changed was the monitor (15" VGA).

Yeah, I found that Video Vision program and downloaded a demo version. I'm checking it out to see if it fits the bill. The good thing about it is that it imports .dbf files directly so our data doesn't need modification; unless the data itself is corrupted in which case it won't run properly in any program.


"'The main program is a .EXE file.'
Q) What is the EXE file's name? Is it DBASE.EXE?

'All other files are .dbf or .ndx'
Q) What other extensions are there (if any)? Any sub directories there?"

The EXE file is called TL.EXE ; where TL is simply the short form of our video store name.

There are lots if file extensions in the "video" directory - no subdirectories BTW;

.ndx
.ntx
.dbf
.udn
.idn
.rno
.rna
.fpt
.ddd
.ddm
.snb
.slb
.sla

and of course, the one TL.EXE

Some of these files are not dBase related; probably they come from another program that I have used over the years to purge data and do other maintenance that the main program does not do. That other program is Alpha 4 DOS version.

Thanks for all input so far.

bobkat

PS: how do I do a "quote" from another post?

 

[dbMark]

It's hard to imagine why in the middle of June it would quit assigning the standard 15-day due date. Any number of reasons, but could it be that the programmer built in some sort of cut-off date, like maybe it would work for only 10 years 1994-2004? Anything about 10 years in the original specs like "supported/guaranteed to work for 10 years", etc?

 

[MiggyD]

Actually, what dbMark said is valid.

I'm currently working on a program for a friend of mine (in VB4). One of my forms uses a [make-shift] calendar. I've given her a 50-year time span [cut-off] for the program--which I'm certain by that time I'll be long gone (and buried) or she'll have a "more modern and up-to-date" program for whatever OS will be around.

A fairly simple way to test to what dbMark said is to change the date to sometime earlier this year and see if it works or if it crashes.

On another note, make sure you test that program vigirously BEFORE it's purchased (especially on w98). Also, I'm not familiar with TL.EXE so I'm unable to help in that respect; maybe someone else here has heard of it?

--MiggyD

 

[bobkat88]

Hi Again:

Thanks for the suggestions. I tried to set the system date back a full year but the app still crashes. I have tried to contact the program writer but he can't be found...

I'm going to keep plugging away at this thing. In the meantime this Video Vision program looks like it will do nicely. I just wonder about importing my existing data. Apparently you have to import it using Excel. That should be a treat.. I have very little experience with Excel. I think I will experiment first by importing 20 or so records and see how it goes.

Thanks again guys.

bobkat88

 

[bobkat88]

UPDATE:

The mystery has been solved...

Apparently the application had reached its maximum for the invoice numbers. The field is a numeric field with a length of 5, and the last invoice number in the IVC_HEAD database was 99,999. So I packed (actually I "zapped" -- LOL)the sucker and also changed the field length from 5 to 6. Everything works OK again.

I think I will still switch over to that Video Vision program as it looks pretty groovy.

Thanks a million for all the replies.

bobkat88

 

[dbMark]

Don't forget that the index number may exist in other tables too, referenced elsewhere in the code as a string/substring value, or is part of an index expression, then there could be repercussions to simply enlarging the field.

For example, an index expression (even in another table) could be: STR(inv_no,5)+DTOC(date_rent)+item_type

 

[bobkat88]

Yes, good point dbMark. This occured to me as well. I think I may change it back to a length of 5. I mean if it took 10 years to reach invoice # 99,999; I've got another 10 years before this issue crops up again!!!

Theoretically it would take 100 years to reach invoice # 999,999 -- so that's simply unrealistic, or extremely wishful fiscal thinking !!! HeHeHe

Anyway, the program seems to be running fine. All I need to do now is figure out how to export the data to Video Vision via Excel.

Thanks again.

bobkat88

 

[MiggyD]

I would not have tought to look at other fields to be the cause of your problems, glad that was resolved.

I was not the initial person that exported the data from my client's DOS program but I can guide you to importing the data into Excel (ver 97 or better--I don't believe Jet 1.0 that came with excel/office 95 is able to do the conversion; but you can try if 95's the only one you have).

start up Excel,
click File,
click Open,
change the File Types (to look for) to either DBF or All,
using the browsing window locate and click on the file you wish to open,
once it's highlighted then click Open.

After it's opened,
click File,
SAVE AS (not just 'save'),
make sure the FILE TYPE is an excel "Workbook" or has the extension of "xls".
and now you're finished creating an Excel Workbook from the DBF file.

That's all there is. Good Luck.
--MiggyD

 

[bobkat88]

Thanks MiggyD:

That helps me a great deal. I have Excel from Office 2000 so it should work OK. First I have to build a faster computer to run Video Vision. I downloaded the demo onto another machine (P4 2.8 GHz with 512 MB ram) - it runs great. Of course with that much horsepower it should...

bobkat88