>Hi Dan,
>
>>Here's the scenario we want to avoid. First process comes in finds the record it wants. Right before it retrieves the data, the second process suspends the first, and moves the record point to the new record. The second process returns the correct data. Now the first process is on the wrong record and returns the incorrect data.
>
>In this regard there's no difference between a normal function and a COM server, as methods are not processed parallel. If the method leaves the environment in the state it found it, there would be no conflict at all. All you need to do is to restore the record pointer, SET variables, etc. before you return.
>
>Alternatively, the method could create an object based on Session and use that new datasession to process all tables.
>
>Christof

We want to keep the table open exclusively, if we can. But, restoring the record pointer would do the trick. We were so convinced that the mutli-use exe was mangling variables as well as the environment. When we were using Rick's Web Connect Com Servers, we had used them as mutli-use. We used a stress test and it appeared that record pointers were being moved, tables were being closed. Variables were suddenly invalid or different then when originally set. We were using data sessions here but it did not appear to matter.

I would think that as long as you're using data sessions, we should not be running into these problems with a mutli-use exe.