>>>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.
someone mentioned an updateable view as a possible solution... and it is...
but keep in mind that each index must be built and all the data must read into the cursor when the view executes.

for the fastest possible filtering against large data tables i recommend interviewing the endusers and find out what fields they most likely wish to 'filter on'...
make sure the table is in FIRST NORMAL FORM ... allowing users to filter on appropriate fields.

have the indexes already built in the table before the application ships.

then each filter command will execute and will be rushmore optimized because you have already built the indexes...

if your end users wish to add new search criteria ....
they can still filter in non rushmore optimized fashion but the table will be much slower...

if the users claim they MUST have a new search criteria...
you can simply add a new index in the table yourself later on .... and charge a nice fat fee to do so....
oops.. thats consultant talk... sorry.