>>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.
>
>There is no way two people can have a table exclusive. That's what exclusive means. Are you buffering this table in any way? You shouldn't be. Can you post the actual code that does this?

Here's the code. I know what exclusive means. I was inquiring as to a VFP bug(a very common occurence). Unless there is some kind of buffering on by default in VFP, there is NO buffering going on.


FUNCTION NEW_NUMBER

*!* Selects first available work area
SELECT 0
IF NET_USE("ORDER_NO",.T.,8)
*!* Uses file exclusive(.T.), retries 8 times See NET_USE function below
STORE ORDER_NO->ORDER_NO TO M->ORDER_NO
*!* Store the current order number from the file to the memory variable ORDER_NO
REPLACE ORDER_NO->ORDER_NO WITH ORDER_NO->ORDER_NO + 1
*!* Incremenet the ORDER_NO in the file by 1
USE
*!* Close the file
ELSE
*!* Simple function to tell what file couldn't be accessed
NET_FAIL('Order Number')
*!* Return to the highest calling function-- cancels current order
RETURN RUNMAIN
ENDIF
*!* Returns .T. to calling function, saying an order number WAS gotten
RETURN .T.



*!* Note-- NET_USE is a slightly modified function originally written by
*!* another programmer in CLIPPER

FUNCTION NET_USE
PARAMETERS vFILE, ex_use, wait
*!* vFILE = Filename to open
*!* ex_use = Logical if it should open exclusive or shared
*!* wait = how many retries to open file

*!* Store value from vFILE to THISFILE in case the file cannot be opened
*!* THISFILE is used by my on error routine to report what file can't be opened
THISFILE = vFILE

*!* Stores .T. to FILEFREE variable
STORE .T. TO FILEFREE

*!* Try to open it WAIT amount of retries
FOR X = 1 TO WAIT

*!* use the file exclusive or shared
IF ex_use && exclusive
USE &vFILE EXCLUSIVE
ELSE
USE &vFILE SHARED && shared
ENDIF

*!* FILEFREE would be changed to .F. in my on error routine if above use
*!* had failed
IF FILEFREE
RETURN (.T.)
ENDIF

*!* Wait 1 second before retrying, turning off the cursor to prevent it
*!* from flashing on-screen
SET CURSOR OFF
INKEY(1) && wait 1 second
SET CURSOR ON
NEXT
*!* Pessimistic return-- can only return .T. if 'FILEFREE' is true above
RETURN .F. && USE fails