Page 4 of 4
Troubles with DBF
Posted: Wed Feb 02, 2022 11:08 am
by Chris
Hi Gerhard,
That's what I thought at first, too, but this does not seem to be the problem. I removed all code related to locking, updating fields etc and the problem still happens. Here's a very cut down version of the code, which still reproduces this:
https://github.com/X-Sharp/XSharpPublic/issues/945
Troubles with DBF
Posted: Wed Feb 02, 2022 11:14 am
by Horst
Hi Chris
All this tmp files are created with X# see :CreateKontrollTemp () in func.prg
Another simular problem:
In the attachements now is a additional corrupted file - sina.dbf (in tmp.zip) also created with x# . After lets say 2 or 3 days updating the memofield i have the same problem. i cant modify this file with dbalite - corrupted ftp. this file runs corrpted also under x#2.6a.
I think there is a problem with the rdd, in vo the same runs since 8 years without troubles.
Horst
Troubles with DBF
Posted: Wed Feb 02, 2022 11:15 am
by Horst
Hallo Gerhard
I tryed it, the same result.
Horst
Troubles with DBF
Posted: Wed Feb 02, 2022 11:19 am
by Horst
And the Tmp files are only corrupted when i compiling with x# 2.10
Horst
Troubles with DBF
Posted: Wed Feb 02, 2022 3:43 pm
by robert
Gerhard,
I found a problem. This issue was caused by code in the runtime that is triggered by AppendDB().
When the source and target files have the same structure the RDD system tries to bypass the FieldGet/FieldPut for each of the fields by directly copying the recordbuffer from the source file to the target file.
However, it should not do that when there are Memo fields involved.
I have already committed a fix to the X# Runtime Repo on Github.
When Chris has validated the issue he will most likely send you 2 updated files.
You can also test this yourself if you add a dummy field to the target structure. In that case the structure comparison will detect that copying the recordbuffer is not applicable the fields are read and written one by one.
Robert
Troubles with DBF
Posted: Wed Feb 02, 2022 5:16 pm
by Horst
Hallo Robert
1.
Will this also fix my post #21355 ? There i dont use appenddb, only fieldput
my colleg doesnt report loosing data, is it possible that empty FTP files make troubles when i use dbalite for modifying the struc ?
2.
I was copy that 5xx tmp files to new tmp files with a field with 1000chars.
many records cant be copied because of the flexfile reading error.
when i jump over the empty (1024bytes) FTP files no problem.
see the function in the attachements.
also no abenddb ()
Horst
Horst
Troubles with DBF
Posted: Wed Feb 02, 2022 5:56 pm
by robert
Horst,
This test program is included with the Github ticket that Chris added. I tested this bug with the program.
See
https://github.com/X-Sharp/XSharpPublic/issues/945
The issue should be fixed in the new build.
The field size does not play a role here. The problem was with memo fields in the source file and/or target file.
Robert
Troubles with DBF
Posted: Thu Feb 03, 2022 4:36 pm
by OhioJoe
Don't know if this helps the discussion but I think it's important to point out there are subtle differences in files created from different apps:
Clipper
FoxBase
DBase IV
FoxPro
Visual FoxPro
X#
and I'm sure there are others. I've used all of these over the years and they all seemed to work in VO. Never ran into any difficulties until X# but our crackerjack development team of Robert and Chris jumped on the problems and fixed things quickly.
Perhaps we need to look at the creation source of the DBFs and compare the behavior of each. As I understand it there's a symbol in the header of a DBF that reveals its format. For example, if the file was created long ago in FoxPro, then it will blow up if the field count extends past 255.
I have no idea how to read or interpret this header but perhaps someone else does.
Troubles with DBF
Posted: Thu Feb 03, 2022 6:24 pm
by Chris
Hi Joe,
The problem Horst reported was indeed a bug in X#, as Robert said earlier and had to do with copying data from dbf to dbf with identical structures. It's already fixed now!
Troubles with DBF
Posted: Thu Feb 03, 2022 7:08 pm
by OhioJoe
Like I said: our crackerjack development team!