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.