 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Mark M
Guest
|
 Posted: Tue Aug 15, 2006 3:16 am Post subject: Weird append problem |
 |
|
I am supporting an older Delphi 4 application. It is a multi user
application that edits and inserts records into a dBase IV DBF residing
on a Netware server. The problem appears only once in a while, maybe
every few days for a period of a couple of hours. The applications are
all sharing this DBF, but sometimes adding a new record using the
append method of a TTable object results in an existing DBF record to
be overwritten. For example, if the DBF contains 100 records, a user
issues an action to add a record to the file, but instead of adding a
record to the end of the file, it overwrites one of the existing 100
records. The code skeleton is as follows:
ATable.Append;
ATable.FieldByName('REF').AsString:= '1234';
ATable.Post;
I inserted logging into the code to tell me which dBase record was
added, because after the ATable.Post, the record pointer should be on
the newly added record. So my code changed to:
ATable.Append;
ATable.FieldByName('REF').AsString:= '1234';
ATable.Post;
// Log the adding of the record
Logit("Added record number "+ IntToStr(ATable.Recno));
The log file will show something like:
....
Added record number 100
Added record number 101
Added record number 102
Added record number 103
Added record number 104
Added record number 88
Added record number 89
Added record number 90
.....
I have turned off all file caching in the Netware client. The Netware
client is up to date except for the W2K machines using a 2 small
revisions old due to conflicts with another legacy application. I have
tried to FlushBuffers after the post, and tried many many other things.
It appears the MDX index file is getting corrupt somehow and seeks
using the keys lead to incorrect records. I have run out of ideas, and
all my ideas are too long to list in one posting. All workstations
are running BDE 5.1 with all the same settings.
Does anyone have any ideas? |
|
| Back to top |
|
 |
Jamie
Guest
|
| Posted: Tue Aug 15, 2006 8:18 am Post subject: Re: Weird append problem |
|
|
Mark M wrote:
| Quote: | I am supporting an older Delphi 4 application. It is a multi user
application that edits and inserts records into a dBase IV DBF residing
on a Netware server. The problem appears only once in a while, maybe
every few days for a period of a couple of hours. The applications are
all sharing this DBF, but sometimes adding a new record using the
append method of a TTable object results in an existing DBF record to
be overwritten. For example, if the DBF contains 100 records, a user
issues an action to add a record to the file, but instead of adding a
record to the end of the file, it overwrites one of the existing 100
records. The code skeleton is as follows:
ATable.Append;
ATable.FieldByName('REF').AsString:= '1234';
ATable.Post;
I inserted logging into the code to tell me which dBase record was
added, because after the ATable.Post, the record pointer should be on
the newly added record. So my code changed to:
ATable.Append;
ATable.FieldByName('REF').AsString:= '1234';
ATable.Post;
// Log the adding of the record
Logit("Added record number "+ IntToStr(ATable.Recno));
The log file will show something like:
...
Added record number 100
Added record number 101
Added record number 102
Added record number 103
Added record number 104
Added record number 88
Added record number 89
Added record number 90
....
I have turned off all file caching in the Netware client. The Netware
client is up to date except for the W2K machines using a 2 small
revisions old due to conflicts with another legacy application. I have
tried to FlushBuffers after the post, and tried many many other things.
It appears the MDX index file is getting corrupt somehow and seeks
using the keys lead to incorrect records. I have run out of ideas, and
all my ideas are too long to list in one posting. All workstations
are running BDE 5.1 with all the same settings.
Does anyone have any ideas?
years ago i ran into a similar problem.. |
what i did was to lock the database for exclusive
access when ever i was adding/updating records.
i would first check to see who had to lock on it
after i had locked it my self. i found that now and
then, some other user would have a lock on it and the
database would collide with no errors to the app.
in this case, i simply attempted another lock until
i got a status back indicating that my app had the
lock on it.
this may not apply to you but it worked for me. i don't
know how much flexibility you have with that DB engine.
--
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5 |
|
| Back to top |
|
|
DB-1
Guest
|
| Posted: Tue Aug 15, 2006 1:58 pm Post subject: Re: Weird append problem |
|
|
Mark M wrote:
| Quote: |
Logit("Added record number "+ IntToStr(ATable.Recno));
The log file will show something like:
...
Added record number 100
Added record number 101
Added record number 102
Added record number 103
Added record number 104
Added record number 88
Added record number 89
Added record number 90
....
|
My ancient BDE experience covers only Paradox tables, not dBase tables.
But I quess that the log listing *probably* should look like that, and
there *probably* is nothing wrong when DBF table behaves that way. When
adding new records, BDE/DBF tries to use and occupy the previously
deleted record areas. And while ATable.Recno returns the physical order
number of each record, the newly added record can easily be added in
"between" some old records.
What is the Table's RecordCount before and after those insertions? If
the new count does not match with the added record count, then you may
have problems.
| Quote: | I have turned off all file caching in the Netware client. The Netware
client is up to date except for the W2K machines using a 2 small
revisions old due to conflicts with another legacy application. I have
tried to FlushBuffers after the post, and tried many many other things.
|
Your code snippet gave no indication how you deal with the Primary index
field in your tables. Is the Primary key field some Autoincrement field,
or do you put the new record's primary Field contents in your own code?
Instead of debugging the RecNo values, you should be concerned that the
Primary indexes in your MDX files are OK, and existing records do not
get overwritten when adding new records.
// Some test code for inserts, use secondary TTable ('BTable') pointing
to the same
// database file, and make sure that there absolutely does not exist
// a record with the same Primary Key already.
if not BTable.FindKey([99992345]) then
begin
ATable.Append;
ATable.FieldByName('ThePrimaryField').AsInteger:= 99992345;
ATable.FieldByName('REF').AsString:= '1234';
ATable.Post;
end;
That code was just a slim and untested suggestion, the problem may be
totally elsewhere. But I think that instead of gathering the RecNo
values your LOG file, you better gather and watch the RecordCount values
and also gather the added record's Primary key values.
And also have a second LOG-file keeping track about Deleted records (in
Table.BeforeDelete events), and their primary key values.
This way you may better find which records have disappeared under your
own control, and which have just disappeared secretly. After app being
one day in production, you should have good log files to start checking.
Of course you could collect the LOG data directly to DBF-tables instead
of text files. That way you could write some simple routine to compare
the main database and the LOG-DBF record contents.
And finally, you have already double checked to have BDE's LocalShare =
True etc. settings on every workstation? These affect to the buffering
of written data, and they must be right, but I do know about the setting
finesses with DBF files.
DB-1 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
