Damian:
Setting the number programmatically does not always work the way you intended it to.
Try using an AUTONUMBER data type instead.
Just make sure you also set a unique constraint on the column as well as setting it as NOT NULL. These are not set as defaults.
If your application can't tolerate "missing" numbers that the AUTONUMBER technique sometimes causes, then it is still important to set the column as NOT NULL and establish a unique constraint on it to prevent duplicates and null records.
Tony
Anthony Schmidt, JD
President
The Computery Ltd.
One East Main Street
Bay Shore, NY 11706
631-665-8100 Voice
631-969-5988 Fax
www.computeryltd.com
| [EMAIL PROTECTED]
12/16/2002 01:35 PM
|
To: [EMAIL PROTECTED] cc: (bcc: Anthony Schmidt/BayShore/SGU_LN) Subject: RE: RTime, Table Locks, and Multiple Users |
I agree w/ using an autonumber, but this sounds like a network caching
problem. I think you should figure this out because if you are fetching
incorrect information in this situation I have no doubt, it may be happening
elsewhere and you not realizing it.
I have almost no experinec w/ NT networks so I don't know where to tell you
to start.
Troy
===== Original Message from [EMAIL PROTECTED] at 12/16/02 10:42 am
>We have 8 users that access a purchase order system over a network. The
>users are running RTime for Windows 1.851 installed on each of their
>workstations running windows 98 or windows 2000. The database and
>programs are located on a separate computer running windows 2000. When
>a new purchase is added to the system a number is automatically
>generated for it. This is where the problem occurs. We have a table
>that stores the current number and is accessed and incremented each time
>a new order is entered. In the code, we set a lock on the table, fetch
>the current number, increment it by one, update the table, set the lock
>off and proceed to the po entry screen.
>
>For some reason, every odd couple of days and entries the number is not
>calculated properly. I have made a log file to monitor the
>assignments. What I see in the log file is that everything is working
>fine for all of the users and then suddenly one of the users tries to
>enter a new po. The number that is fetched from the table is
>incorrect. I have seen it fetch a number that was used 10 POs ago or
>maybe a number that was used 3 POs ago. I don't understand how.
>
>I know that when RTime exits normally it erases the $$$ files and if not
>then they are left alone. Is it possible that one of these is getting
>re-used and supplying incorrect information.
>
>Any thoughts, suggestions, ideas are greatly appreciated.
>
>Damian
>
>================================================
>TO SEE MESSAGE POSTING GUIDELINES:
>Send a plain text email to [EMAIL PROTECTED]
>In the message body, put just two words: INTRO rbase-l
>================================================
>TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
>In the message body, put just two words: UNSUBSCRIBE rbase-l
>================================================
>TO SEARCH ARCHIVES:
>http://www.mail-archive.com/rbase-l%40sonetmail.com/
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: INTRO rbase-l
================================================
TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: UNSUBSCRIBE rbase-l
================================================
TO SEARCH ARCHIVES:
http://www.mail-archive.com/rbase-l%40sonetmail.com/
