>>Is there any instance in a multi-user environment where two computers/sessions might both open up a file exclusively for read-access without giving me an error when it can't write after reading? Here's the problem I'm currently facing:
>>
>>
>>I have a POS app which has run for years(originally written in Clipper and released in VFP form roughly 1 year ago). In the past 4 months or so, I've had roughly 3 of these occurences(50-500 orders each day per turnkey system-- about 40 VFP turnkey systems in current use), giving me an approximate .00031% occurence rate(200 orders a day on 40 systems for 120 days(approximately 4 months)). Very rare, but people notice when things go wrong. Here's the scenario:
>>
>>When saving an order, the programs uses an ORDER_NO dbf file exclusively(on record, one field). It tries 8 times with a delay between retries-- it will give an error if it can't open the file after 8 retries. Once the program has the ORDER_NO file, it reads the current Order Number(6-7 digit depending upon system's history/original setup) then increments the order number in ORDER_NO by 1(uses a simple REPLACE command). Then it closes the file, and continues saving the order. Exclusive use of the ORDER_NO file prevents other users from opening it up at the same time and getting duplicate order numbers. However, as I said before, I've had roughly 3 reports of duplicate order numbers in the past 4 months. Is there any bug, issue, problem, or my favorite-- undocumented feature in VFP I should be aware of that would cause this? Any proposed workarounds/checks? Thanks.
>
>If your NOS is Novell and you're using the Novell Client32 client, there are some known issues. You can search other threads for suggestions. Basically, they boil down to using the latest version of the client and turning off various go-fast options in the client configuration.

No, we don't use Novell. We actually use WIN98 for all computers in our turnkey systems.....