>Hi Cetin,
>Yes, a single check is fine. The user on the POS app will be informed if the TOTAL sale amount
>is > current balance. The Account would then be unlocked while the POS user can modify the
>sale reducing the total sale amount. Once they have reduced the total sale amount, they could
>again submit the sale for posting.
>
>Yes, it is true this could go back and forth if users of the ITF app were constantly reducing
>the Account balances. That is NOT what really happens business wise, and never will.
>
>Your response:
>
>

>sum sales_amt to lnSalesTot for SalesID = m.luCurSaleID && luCurSaleID is current sales' id
>select Customer && From ITF
>if !seek(m.luCustomer, 'customer', 'CustomerID') ;
>  or customer.Balance < m.lnSalesTot
>  * Customer unknown or Balance is not suitable
>  return .F.
>endif
>

>
>No problem with that part. I understand and perfectly OK.
>
>Your response:
>
>

>set reprocess to 1
>declare Sleep in win32API integer
>ltStart=datetime()
>lnTimeOut = 30
>do while !rlock('Customer') and datetime()-ltStart < lnTimeOut
> Sleep(200)
>enddo
>* set reprocess to old setting
>* Either locked or timed-out
>if !IsRlocked(recno('Customer'),'customer')
>  * Sorry timed out connecting to backend
>  return .f.
>endif
>

>
>Sounds like the above is so that VFP tries for a little while without even telling the
>user. If so, that's OK and I understand.
>
>I believe it would be better if we just forget (for this conversation), about the
>local stuff. I understand what needs to happen locally. It just gets too complex
>for me to discuss.
>
>Cetin, I believe I understand what you and possibly Hilmar are trying to tell me.
>Are you saying, Yes, you could do that in an error handler but you could also just
>handle the RETURN .F. in the above code where this save stuff is occurring.
>
>Is that correct?

Yes VFP is trying to get a lock for 30 secs there. It's not silent in fact but I only coded the skeleton off the top of my head. In real world that code is likely to succeed at first attempt and (thinking connection is fast) proably the sales would be recorded at fractions of a second. It's a very little possibility multiple stations would try to modify the same customer's balance at the same moment but it counts it might happen.
For simplicity of skeleton code I return .f. Normally I'd write this in a class and set some property of class for notification message. In that lock trying loop you might ask user 'Timed out waiting a response..Do you want to wait' and retry for another n seconds (but again 99% it'd succeed on first attempt w/o a delay - don't ask how I calculated:). It's poor man's try...catch block.
Cetin