Anmol,
Are both of the processes UniVerse processes, or is one of them an external
process (script, executable etc.)?
If the latter, some contention at the OS level is probably inevitable, with
the other (non-UV) process having the file open. Whenever I have had that
combination, I always use a
A known cause of UV error 040019 (my guess for Anmol is
Variation-on-the-Theme #2):
When processA is holding the update lock on a record,
and processB issues a WRITE to that record,
then processB will wait for the lock for 20 minutes (non-configurable),
then abort or take ON ERROR clause with
Jerry,
I alwys like this sort of a protection against overwriting:
100BASE.ID = 'ZZZ' : '.' : DATE() : '.' : TIME() : '.'
101DONE = FALSE
102TIEBREAKER = 1
103LOOP
104 READU DUMMY FROM BASE.FILE, BASE.ID : TIEBREAKER LOCKED
105
.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Key Ally
Sent: Wednesday, July 20, 2005 10:30 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] DATABASE write problem
Jerry,
I alwys like this sort of a protection against overwriting:
100
Sent: Wednesday, July 20, 2005 12:12 PM
Subject: RE: [U2] DATABASE write problem
It can actually be done without the loop. Simply increment a unique
sequential number for every record written so that the key has at
least a time and the sequential number. If multiple records come
through in the same
The entry for 40019 in the SYS.MESSAGE file isn't too helpful...
CT SYS.MESSAGE 040019
040019
0001 WRITE failure.
0002
I would suspect that the write is failing at the O/S level. A starting
point would be to check system logs for disk errors, etc.
HTH
Jeff Fitzgerald
Fitzgerald Long,
Is there a possibility that the consumer is opening and processing
through a file that is being reopened in the creator? There might be
some weird OS timing issues in that situation.
We ran into this a while back with our credit card server; for drop
file interfaces we had to follow a specific
