>>>>I answered my own question. The users don't have a config file, therefore the cursor is getting created on the server instead of on their hard drive. Once the first person creates the cursor index it seems to lock it up. Stupid.
>>>>>
>>>>>Laurisa Watkins
>>>>>Seattle City Light
>>>>>laurisa.watkins@ci.seattle.wa.us
>>>
>>>No, that still wouldn't be the answer. A cursor would be unique to each user anyways, even if it was created on the server. More likely an access rights issue than that.
>>
>>----
>>well, once I hardcoded the file to their c:\temp\xxx.cdx it worked just fine. IT's sucky code, but I'll fix it once I've thought about it some more. As a side note, something I found in another part of the app (multi developer environment), when he needs to do this, he uses INDEX ON whatever TAG tagname without specifying to "file name". I need to test it, but I'm wondering if it makes a "unique" temporary cursor index; since no one's complained about his section for ages, I can only assume that's what it does. Thanks.
>
>I've *never* had to specify where or what to call the .CDX file. I've always just issued:
>INDEX ON whatever TAG whatever
>and that's always worked for me.

PMFJI: I think you found the real solution, Laurisa. Seems to me the file contention in the original message was due to using the hard coded CDX filename on the server for all users. Each user would have distinct cursor filenames, but try to use the same CDX filename (which of course is trying to be exclusive use) -- a recipe for disaster in a multi-user environment... Indexing by tag name only on the updateable cursor automatically handles that problem as each user gets a unique cursor filename and cdx filename.

Actually, IMHO, indexing on any table should ALWAYS just reference the tag name and NOT an index filename to be used -- else you will probably have the CDX get saved (and not automatically erased) even though the cursor 'dbf' (*.TMP) automatically erases itself when closed. Also, specifying a filename for a CDX that does not exactly match the dbf filename will make it NOT be a 'production' index (ie: associated with the table), and therefore will not automatically open when its (non-cursor) table is opened -- especially if you use memvars with paths/drives in them for these filenames, and the CDX ends up on a different drive or directory than where the references table is located. Worse, if the DBF still thinks it has a 'production' CDX in another location but that location is not available at time of opening the table (ie: different drive mapping on network, etc.), it will cause an error. So, not only is the code easier to read and understand without specifying CDX filenames, it is 'safer' for letting FP/VFP manage its own files automatically.

HTH

Rob