Mysterious file restore on Windows 2000 Server 1

[MailMan2]

We have a process which creates entries in a table with a sequential ID number. This ID number is obtained from a one record "system" table, and this record is updated with the next available number immediately after. The problem we have encoutered on a couple of occasions so far is that it seems this table gets restored to an older version. I say this because we see the ID number getting used over and over again at different times of the day and sometimes the next day.

Has anyone experienced this or something similar?

Thanks!

 

[Bozz]

Hi Mailman2
Are you running on a W2K or NT server? In which case it could be opportunistic locking.

Are you issuing a commit directly after updating the record?

Are you locking the record before you read the data or just prior to updating it in which case a busy times sombody else could get in there? Ian Boys
DTE Systems Ltd

 

[fmoore0001]

A question that might apply to me in another situation. What is opportunistic locking?

Frank

 

[Bozz]

My understanding is, it is where, when using Windows NT based servers, the server locks bits of files for workstations (with the aim of improving performance)and can fail to keep everthing up to date for other workstations. There are registry fixes and it you think this may be your case post a question on comp.lang.clipper newsgroup. Ian Boys
DTE Systems Ltd

 

[MailMan2]

Hi Ian Boys,

We are running on a W2Kserver.

Yes, the code is issuing a commit directly after the update.

We are locking the record just prior to updating it.
We have two incidents of this problem happening on two separate servers. On one instance, it looks like the entire SYSTEM table was restored because there are 3 IDS sequence generating fields in the same table and all the 3 IDS are duplicated. However, on the other instance, it does not look like the entire SYSTEM table was restored because only 2 of the 3 ID fields are duplicated and they don't duplicate at the same pace.

Thanks.

 

[pratapgharge]

Yes, Even we have faced this problem of getting same sequence number again and again by different terminals. We are using rlock() just before update, and updating record if rlock() is successful. The same software is working fine with Novell netware, but gives this problem, when attempted on win2k server. Is there any way to overcome the same ??

 

[Bozz]

There is a registry fix. It's not a problem that I have but I'll try to get back with an answer. Ian Boys
DTE Systems Ltd

 

[Bozz]

Take a look at:

http://www.jsiinc.com/subc/tip1400/rh1447.htm

Thanks to Klas Engwall for the link. Ian Boys
DTE Systems Ltd

 

[MailMan2]

pratapgharge,

We were glad to hear we were not the only ones experiencing this, and much like you never had this problem before on out Novell Servers.

Ian,

Thanks for the link... we are sending the info to our server support/managers for review.

Will keep you posted on the results.

MailMan2

 

[pratapgharge]

Hi Ian Boys,
DTE Systems Ltd.

Thanks for your help providing the link from

http://www.jsiinc.com,

but after trying all the registry changes recommened there, also we continue to face the same problem of getting same serial number for two terminals. We tested the solution today itself, and is failing. Any other recommendations please.
Thanks & Regards.

Pratap

 

[Bozz]

Pratap,

How about you tie the ID number to the record number of the database or look at the database and find the last record ID and add 1 to it.

I have, in the past, created a quick and dirty log, for example time, date, user ID/workstation ID and the ID number used. Just append a new record to the log file each time. If you index on ID number then you can write a quick program to scan for duplicates periodically. At least this might show when and what is happening.

It is unlikely to be a file restore, that doesn't happen without a good cause, not updating is more likely to be the cause.


Good hunting
Ian Boys
DTE Systems Ltd

 

[pratapgharge]

Hi Ian Boys (Bozz),

By implementing COMMIT statement after repl or delete during rock() and just before unlock and with the steps given by your suggested link

http://www.jsiinc.com,

my problem of rlock() failure is resolved. During primary testing the problem of getting same serial number by two terminals seems to be resolved. Exhaustive testing is going on.
Thanks for the help.

Pratap

 

[pratapgharge]

Hi Ian Boys (Bozz) / Hi all Clipper experts,

The exhaustive testing reveals that it is still failing in some cases. Apart from getting duplicate serial numbers, it is also not able to keep all the indexes updated, resulting it to allow duplicate document numbers. Do you have any other suggestions please ?

Pratap