dbase crash at record no.9999 3

[Dazmac]

Hi Guys,

Kinda new I'd be here one day.

http://www.tek-tips.com/viewthread.cfm?qid=159550&page=1

explains how / why etc.

The dbase program my father wrote controls stock and sales from my brother's garage. After many years faithful service, he sold an item that happened to be invoice no.9999 and that was the end of the show ! Not being any kind of dbase programmer, I'm guessing that the field length is four digits. Is there a way a dbase virgin can find and change this to 5 ?
Or can I zap the existing ones and start again from zero for a few more years service ?

Any help gretly appreciated.

Dazmac

"any sufficiently advanced technology is indistinguishable from magic " - Arthur.C.Clarke

 

[LyndonOHRC]

This should be pretty simple stuff.

Do you have dbase? Do you know how to use it enough to get the database open?

If you do you need to open the database(s) that have the invoice number field in it and from the dot prompt edit the file structure using the command "modify structure".

If you understand almost nothing about this advise so far you will have to find a dBase consultant.

Before doing ANYTHING make a backup that you are absolutly sure you can restore to.

Even after you modify the structure several more things will need to be checked. I'll watch for any reply from you...

Lyndon
rlp@ohrc.org

 

[MiggyD]

That link you posted should be thread290-159550 otherwise that link won't work.

LyndonOHRC is correct in that you should create a restorable backup copy before any sort of tinkering with either the database and/or the program code.


Question 1
IS the db's invoice number scheme maintained for tax purposes? If so then I'd lean moreover to the "modify structure" command as was mentioned by LyndonOHRC.


Question 2
IF not, then you have two options (as I see it):

1) "ZAP"-ing the records and starting from zero,

OR

2) Change the original code to either:

a) reset the count to zero and overwrite the existing records,

OR

b) automating the zapping of the data and restarting at zero.

In either case, you'd need to have access to the original code which was usually saved with the *.PRG extension.

Do you have the original PRG files or is it an EXE that is run?

--MiggyD


--> It's a bird! It's a plane! No, it's an OS update patch! Ahh!! <--

 

[ZoDra]

Hi Dazmac,

You shoul do EXACTLY what LydonOHRC suggested:

1. BACK UP ALL DATABASES AND PROGRAMS
2. IF YOU DO NOT KNOW ANYTHING ABOUT DBASE, THEN FIND A CONSULTANT

Like LydonOHRC said, solution is plain simple to one that knows basics of dbase.

ZoDra

 

[LyndonOHRC]

Hey Dazmac????

How did this issue work out for you?

Let us know...

Lyndon

 

[Dazmac]

Thanks guys for all the advice so far.

Due to difficulties working on the PC in a garage environment, I've got him to drop the PC off at home for me, will be the weekend before I manage to attack the problem. Will keep you all up to date.

Thanks again.

Daz

Dazmac

&quot;any sufficiently advanced technology is indistinguishable from magic &quot; - Arthur.C.Clarke

 

[Dazmac]

I've had the PC delivered tonight and had a quick look. The dbf files in question are strangely not up to invoice 9999, they're still at 9997. The invoicing program however crashes out with a General Protection Exception when I try to run it.

Looks like a fun weekend ahead

Dazmac

&quot;any sufficiently advanced technology is indistinguishable from magic &quot; - Arthur.C.Clarke

 

[LyndonOHRC]

Do you know how to use dbase?


Lyndon

---People Remember about 10% of what you say ---They never forget how you made them feel. Covey

 

[Dazmac]

I used dbase many years ago, it's slowly all coming back to me now, having looked through the .prg files.

I've set echo, talk and step on and found the crash occurs when it open a dbf file of customers.

I have zapped this file and the app now runs. My brother has provided me with paper copies of invoices 9998 and 9999, so they were done but do not appear in the invoice dbf file.

I'm guessing??? that the app has crashed at the garage, leaving the tables open and corrupted.

I've modified the structure to change the invoiceno field to 5 digits. I then had to modify some invoicing searching code in the prg that only allowed the input of 4 digits for a search. So far so good.

What are your thoughts on the crash / corrupted table theory ?

Will battle on and thoroughly test.



Dazmac

&quot;any sufficiently advanced technology is indistinguishable from magic &quot; - Arthur.C.Clarke

 

[LyndonOHRC]

open a copy of the file that is not zapped and from the dot prompt type the "count" command.

Does the record counter in the status bar say eof?


Lyndon

---People Remember about 10% of what you say ---They never forget how you made them feel. Covey

 

[Dazmac]

the customer dbf file reports EOF in the staus bar (EOF/3105)

the parts file also reports an EOF (EOF/2187)

the order file however does not - (18176/18196)

nor does a second invoice file (order summary) (7287/7289)

So I take it that's where the problem lies.

Thanks for your help so far. I've copied everything to my PC and have managed to get the thing working, I now have an EOF in both of these, but not sure how I got it repaired. Was very late last night when I finished, but it seems to be working. I just need my brother to check the full functionality as I'm not sure of how he uses every part of it.






Dazmac

&quot;any sufficiently advanced technology is indistinguishable from magic &quot; - Arthur.C.Clarke

 

[LyndonOHRC]

I can tell you how to fix the invoice file. Then all should be well...

follow these steps on a copy of the database:

1. use invoice
2. copy to temp1
3. 7289
4. copy rest to temp2
5. use temp1
6. append from temp2
7. copy to invoice
8. use invoice
9. count

if you are at eof then it is fixed.

Next you need to reindex all of the indexes.

Does the system have a reindex menu choice?

Your situation is what I've always called "a hole in the database". Usually caused by loss of power to the pc or system lockup with a dbf open.

I've fixed this kind of thing a thousand times.

Let me know how you are doing...



Lyndon

---People Remember about 10% of what you say ---They never forget how you made them feel. Covey

 

[Dazmac]

Thanks Lyndon,

Am away from the PC at the moment, but your explanation sounds good.

There is no re-index menu in the program. I hold my hand up and say I don't understand the reindexing.

In the program there are reindex commands as follows

USE INVOICE INDEX ORDER
REINDEX

USE PARTS INDEX PARTS
REINDEX

Cheers,

Dazmac

Dazmac

&quot;any sufficiently advanced technology is indistinguishable from magic &quot; - Arthur.C.Clarke

 

[Dazmac]

oops,

the code above should have read;

USE INVOICE INDEX INVOICE
REINDEX

USE PARTS INDEX PARTS
REINDEX



Dazmac

&quot;any sufficiently advanced technology is indistinguishable from magic &quot; - Arthur.C.Clarke

 

[LyndonOHRC]

You're on the right track.

After you repair the database corruption I explained in my previous message.

Use a text editor to search all occurrences of "reindex" and "index on" in all of the PRG extension files. In dbase only the first four letters of any command is required. It could have been typed "inde on" for "index on" or "rein" or "reind" for reindex. All of these possibilities are synonymous.

Duplicate all of the reindex instances from the dot prompt as in:

USE INVOICE INDEX ORDER
REINDEX

Then duplicate the index on commands with the “Use” command, you should find above it in the source code, as in the example below.

Use parts
Index on partno to parts
Use invoice
Index on dtos(inv_date)+inv_number to order date.
Close all

Make sure you duplicate all of the reindex instances before doing any "index on" instances.

Then the only trouble you should have is with the new length of the Invoice Number field. The system could have been written where you will have no further problems.

Let me know...


Lyndon

---People Remember about 10% of what you say ---They never forget how you made them feel. Covey

 

[Dazmac]

Everything now working, only the print functions to check when I take it back to the garage -should be ok.

Seems to be no problems with the modified structure of the invoice field length.

Many thanks for all your help.

Will advise tomorrow if it passes the print test and is 100%.

Thanks again.


Dazmac

&quot;any sufficiently advanced technology is indistinguishable from magic &quot; - Arthur.C.Clarke

 

[LyndonOHRC]

Very good. Glad to help.

Lyndon

---People Remember about 10% of what you say ---They never forget how you made them feel. Covey