insert creates 2 records (in exactly one case)

  • Follow


Hi,

another strange observation with btrieve.

We observed in a single case (only *one* occurence), that a single
call of insert (code 2) creates two records.

The PSQL server engine has Version 8.70.14.000, local cache engine was
deactivatet on the workstation (the server allows local cach engine
connections: we will switch this off soon).

Our application runs in that special envrionment for more than 10
years with thousends of inserts a day: this never never occur: only in
that one singular case.

(Also in other environments still unsing PSQL 8.x this never happns
(same application running))

unfortunately in the logfiles (pvsw.log, system log of windows botzh
server an workstation) where nothing. As this happens, there where
only one user activ in the system. The database was not in continous
operation mode (this ends about 10 minutes befor the doubble record
was created).

Our application adds a additional record to a logfile upon *every*
update or insert operation to databasefiles. The add to this logfile
is made immediately after the update/insert.

In this logfile there is only one entry, but there are two (identical,
but with correct incremented autionc) records in the databasefile. I
mention this to illustrate, that the application definitely does not
call insert twice (because if so, there must be a second entry in the
logfile).

In the logfile the statuscode of the last update/insert and the
autoinc-number is saved: therefor I know, that the insert-call that
procuced the 2 records, has returnd statuscode 0; the autoinc was that
from the first record. (There where no time beween the first and the
second record.)

Does anybody know, what the reason for that strange thing may be?
Networkproblem? spillover effect of the COM(continous operation mode:
it was opened and closed with butil: which is done automatically twice
every day (for updates) without any problem in the last years)?
Other?


Regards
Mircea




0
Reply nmm 3/18/2010 3:49:25 PM


0 Replies
250 Views

(page loaded in 0.069 seconds)

Similiar Articles:











7/29/2012 10:51:52 PM


Reply: