>>>>I have a form that displays individual customers. My application allows users to have multiple instances of this form open at any one time. Each form has a private datasession and has buffering set to 5. The form has the usual step forward and back buttons to allow users to step through customers. The form also has a filter button which calls a modal form to collect criteria for filtering the underlying table. The criteria is returned as a string which is then used to build a temporary index and thereby allow users to filter the underlying table and step through only those customers meeting the criteria.
>>>>
>>>>This works fine when I have a single customer form open. When I have two customer forms on screen the index command errors with "Command cannot be issued on a table with cursors in table buffering mode (Error 1579)". I have set buffering to 1 before the index is built and reset it afterwards, but this does not help.
>>>>
>>>>It appears that even though the 2 forms are operating with private datasessions the index that is being built in one form is interfering with the underlying table in the second form. Is this to be expected?
>>>>
>>>>Thanks
>>>>Barry Sutton
>>>
>>>In order to add a new index to a foxpro table EXCLUSIVE use of the table is required.
>>>Thus, you cannot use the above strategy in a multi-user situation.
>>>
>>>If anyone knows of a technique allowing muliti-user access as a table is being reindexed... let me know.
>>>
>>>HTH,
>>
>>Dave,
>>
>>That thought went through my mind but, why do I get this error with a single user who has multiple instances of the form open but do not get the error when there are multiple users (different PCs) accessing the customer table?
>>
>>Barry.
>
>behind the scenes... each separate datasession is performing a USE on the table and it is in SHAREd mode...
>each separate datasession is 'in effect' and for the purposes of this discussion a separate 'USE'r of the table


Dave,

Sorry if I am being a bit slow here, but I cannot see why I do not get the error with multiple users on different PC's who are also USEing the tables in SHAREd mode. Surely, the error should still manifest itself as a conflict on access to the shared table across the network.

Barry.