We have Novell here. I have never had any problem with Buffering = 5. The RLOCK is a possible problem. Instead of SCAN ...RLOCK....ENSCAN, try:
UPDATE pireq ;
SET dbilled = m.idate
This locks the header in the buffer/table and will keep your locking contention lower.
What version of the Novell client are you using? Server version doesn't matter as much. To get this, you should have a big N in your notification area on the start bar. Right click on this and then click Properties. On the Client property sheet, there is a Client Version. Certain Versions of the client have file locking issues. These are corrected in the newest versions.
Also, if the TableUpdate returns false it is a good idea to immediately issue AERROR(). This will tell you what is wrong.
HTH,
Richard
>I have a problem which I cannot reproduce when I debug the version of the program on my C drive. If I copy the code to a mapped Novell drive I can reporduce the problem. The user runs a form and press on a button which invokes a "click" method. In it I check if tables where update and if not display an error message. I find that the second tapeudate reuturns ".F." Tables are buffered and buffering is set to 5 (optomistic table). Variables are declared as LOCAL variables. Billset is a cursor.
>
>llTableUpdateii = TABLEUPDATE(.T.,.F.,'ii')
>IF llTableUpdateii
> *update issue records with this bill date
> SELE billset
> SET ORDER TO creqno IN pireq
> SET RELATION TO creqno INTO pireq ADDITIVE
> SCAN
> llRlockpi = RLOCK('pireq')
> IF llRlockpi
> SELECT pireq
> REPLACE pireq.dbilled WITH m.idate
> ELSE
> llOk = .F.
> EXIT
> ENDIF
> ENDSCAN
> llTableUpdatepi = TABLEUPDATE(.T.,.F.,'pireq')
> IF NOT llTableUpdatepi
> llOk = .F.
> ENDIF
> SET RELATION TO
> USE IN billset
> USE IN billtotl
> ELSE
> llOk = .F.
> ENDIF
>ENDIF
>
>I do
NOT understand what is happening. Any help appreciated.
State of Florida, DCF