GPF on dbcommit(), commit in Clipper 5.2(e)

[JacquesJTheron]

We have been using DBFCDX RDD in Clipper 5.2(e) for some time with good resuslts. Recently got intermittent GPF's on dbcommit() and 'commit' commands after adding new records to some *.dbf files. The file in question has two tags, consisting op 5 and 6 columns in the database combined to make up the index key. Linker is Blinker version 3.3. BLIGPF.exe reports the offending segment of code to be __BMOVE(). The problem was found in two programmes (*.exe's) accessing a file with the same name, structure and index tags - but on different machines and disk drives - ie not the same file - just similar.
Apart from the comment on Blinkers Web FAQ that the problem was reported and acknowledged by CA in December 1995, I have been unable to find a fix or workaround for the problem. (Apparently CA said at the time that they were working on the problem....)
(It seems to happen on the first record in the file - with each GPF it adds a blank record to the file, and a reindex fixes the problem for a undeterminate period - I think till the file gets emptied and packed)
If anybody has any more information or suggestions, I would like to hear of them. Maybe someone knows of a patch, or even has a replacement *obj for __bmove??

 

[DTracy]

Jacques,

Could you post the two Index statements for the tags so we can see them?

I had a similiar problem and had to change the way I created the tag in order to solve. My problem involved indexing a logical field and the way I created the tag as well as the way I searched the tag. When I did a dbSeek(), it would GPF.

Thanks,
David Tracy

 

[JacquesJTheron]

Hi David - thanks for the respones
The structure of the files are as follows - just do a dbcreate with aDBF as structure array.
aDbf := {}
aAdd(aDbf, {"RECEIPT" ,"N" , 12 , 0 })
aAdd(aDbf, {"CASHIER" ,"C" , 5 , 0 })
aAdd(aDbf, {"BRANCH" ,"C" , 4 , 0 })
aAdd(aDbf, {"PDATE" ,"D" , 8 , 0 })
aAdd(aDbf, {"TERMINAL" ,"C" , 10 , 0 })
aAdd(aDbf, {"PAYTYPE " ,"C" , 20 , 0 })
aAdd(aDbf, {"PAID_IN" ,"N" , 14 , 2 })
aAdd(aDbf, {"CHANGE_OUT","N" , 14 , 2 })
aAdd(aDbf, {"FOREX_RATE","N" , 7 , 3 })
aAdd(aDbf, {"TIM" ,"C" , 12 , 0 })
aAdd(aDbf, {"CODE" ,"C" , 12 , 0 })
aAdd(aDbf, {"TRANTYPE" ,"N" , 2 , 0 })
The index expression is as folows:
tag 1: str(receipt,12,0) + dtos(pdate) + terminal + cashier + branch
tag 2:str(receipt,12,0) + dtos(pdate) + terminal + cashier + branch + paytype
These are placed in character strings and indexed by a call to a udf where the following happens:
Index on &(cFld_Name) tag &(cNtx_file) EVAL ;
{|| MYMETER() } EVERY MTR_INCREMENT
cFld_Name is the index expression above, whilst cNtx_file - a relict of the older days would contain say "receipt", or whatever. I index well over hundred other files in the same way, with hardly ever a problem. (On occasions found problems which went away when the offending record in the database was removed...)
Regards
Jacques Theron