>Jim,
>
>I was always using meaningful names for my cursor (like TEMP_CURS <g>). And I understand that the actual table name on the local drive is unique. But I was thinking, what if the same class gets used at the same time and the application tries to create TEMP_CURS again, where it already exists. Hence, the problem. So I am going to switch to the sys(2015) approach.

Using datasession object will mean that each session can have cursors with the same name without anything interfering with anything else.

I know of one place that used a public variable to create a "unique" cursor name based on a patient record.

When this public variable got changed in the code, scheduled treatments were "moved" to another patient. Because these people didn't want to learn or change, they put patient lives at risk. They thought their technique was so clever too.

Never use public variables. Use private data sessions.

>
>Thank you very much for your help.
>
>
>>Dmitry,
>>
>>Cursors are meant to be named with meaningfull names that it easy to work with them. The underlying table name (if a disk presense is needed) is always unique. So unless there is some specific reason you should use non-unique cursor names so that you have an alias that is usefull to you.
>>
>>

>>SELECT * from Mytable INTO CURSOR CurrentResult NOFILTER
>>
>>?DBF("CurrentResult")
>>

>>
>>The above code will show you that the cursor CurrentResult has a unique table name on the machine, so you can use the meaningfull cursor name CurrentResult as your cursor name and alias. If you absolutely need to have a unique cursor name and/or alias then use something like this;
>>
>>

>>lcCursorName = SYS(2015)
>>
>>SELECT * FROM MyTable INTO CURSOR (lcCursorName)
>>
>>

>>
>>And the variable lcCursorName has your alias in it.