Hi Scott,

I'm going to go on a hunch here, bear with me.

What is the relationship between the procedure that zaps and loads the table and the form with the grid? I'm thinking that if you isolate the routines that create the new table in one block of code, then close the table, then use the table in the datasession of the form (use private datasession) your problems might go away.

>I have a simple form with a grid, and a set of grid buttons. I am using VFP 6.0. This app begins with a program which opens a free table exclusive, zaps it, then rebuilds it with a rather large SQL Select. The free table is a work file. It consolidates data so the user can see everything she needs at one time. She schedules deliveries with this. Since we are delivering upwards of 100 loads of roof tile daily, a lot of judgement is needed to schedule it. There's currently no hard core set of rules which will allow me to automate the delivery schedule. Anyway, the user edits this table in a grid, enter the crew IDs and exit. But the changes are not applied to the table. I looked for buffer settings, thinking this may be the problem, but found nothing suspicious. I then went back to the originating program, closed the table and re-opened it shared (it was excl). Now the update works. The problem is, I cannot find this "feature" documented anywhere. If Microsoft fixes it in a
>service pack, my app will no longer work. Is anyone aware of this? It really seems that an exclusive open would entitle the user to more rights, not less. By the way, one person does this. It is not a shared app (at least not yet).