If it is only a cursor, then it does not create a problem. Cursors are local and in exclusive use of the user that created them. The problem may arise only if the server tries to create multiple results from the statements (and cursor names) received from somewhere else.

This is my interpretation of the task, since we do not have the exact scenario how the clients interact with the server. (tell me if I am not correct).

So, if I understand correctly from the details provided, there is a VFP server that somehow receives the requests from the clients and executes the corresponding SQL statements into the cursors. Then the clients should identify their results by the unique name of the cursor, I assume. The SQL cursor (table?? Or another part of server code that handles the results??) should exist for a while until it is picked up/processed, while the server may execute the next request. That's why the unique cursor names may be requred. The results should not be overwritten by the next SQL request.

If the cursor names are generated on the server, then everything works OK (however, I do not know how the result cursors are processed in this particular case, and how they are recognized by the clients - there are several ways to do that, for example convert and return as XML). If the server receives the cursor name generated by SYS(2015) from the client as a part of SQL statement, then there is a problem, since SYS(2015) values are generated on the different PCs and may be not unique.

I have similar FoxPro server working in production for about 2 years. It exchanges requests/results as DBF files, so the final result goes into TABLE. It's not a simple SQL statement execution, but more complex data processing that is capable of executing about 30000 requests per hour, handling about 10 GB of FoxPro data (and growing :).

In my case, the uniqueness problem was even worse, since it had to work under FoxPro DOS, so I had only 8 character for the filename. I worked around this through error handling and checking the original request's data that were returned along with the result. It is allowed to overwrite someone else's requests/results in the process, so the client will just repeat its request until it gets the related result. There is a reasonable number of retries, of course, so it does not go into the endless loop.

>Nick,
>
>If a program running on two separate systems runs a query into a cursor with the same name, this does not cause a problem at all, right? They can't see each other...
>
>>Note that SYS(2015) is unique only on one PC, it is not good enough to use on the network as is. If your cursor names are generated only on the server that should work. If not, you need at least to add some kind of prefix (for example network user ID or machine name). And, considering the 10-character limitation, adding the prefix will decrease the uniqueness of the value generated by SYS(2015). Of course, only GUID guarantees the true uniqueness.
>>