Hi Ray,

sorry, took me a while to reply.

In a job processing software I wrote some years ago I noticed a similar effect as you did regarding the success rate of RLOCK() on two machines. One machine would be able to lock records by a magnitude more often than the other. On way round this I found was to use the Sleep function with a random interval:

Declare Sleep in Win32API Long
Sleep(Rand()*50+10)

You need to call RAND(-1) at the startup of your program.

To solve the TABLEUPDATE() issue in your loop, it might help to open the table when updating each record. This would mean that you use GETNEXTMODIFIED() on the original table to find the next modified record. Then use the table again in a different work area, transfer the record using SCATTER NAME/GATHER NAME, issue TABLEUPDATE() on the copy and TABLEREVERT on the original record. If the record has been deleted, you need to duplicate the DELETE, for new records the INSERT/APPEND BLANK statement. Finally close the second table and proceed with the next record.

If this doesn't work, it might help to serialize all updates. For this, create a DCOM server that takes the SCATTER object and some additional information like table name and operation (DELETE, INSERT, UPDATE). The COM server would perform the TABLEUPDATE whereas the desktop application uses TABLEREVERT. Compile into a multi-use server (a setting on the project info dialog). Then configure the COM server to be accessible from all users logged onto the terminal server, but change the identify to a single account. This way, only one instance of the COM server should be launched and shared by all users (at least that's the plan, but I haven't tested it).