That's what I would have thought would be the process, that at least makes some predictable sense. However, what I'm seeing is that it's processing them in the reverse order ( I checked again) - in the order displayed from top to bottom in the data session window. The last table opened is the first one processed. I suppose as long as it's consistant, I can live with that, but thought it was an interesting oddity. --- Just did more checking/digging in the updaterows method and FOUND THE CULPRIT! What's doing the deed, as it were, is the following: It grabs the list of tables using the AUSED(arrayame) command, which looks at the current datasession (in the order displayed - top to bottom - there must be a little legacy code in there somewhere, going from lowest to highest work area), then the for loop runs through and selects (arrayname(i,1)). Is there a command like AUSED() that goes through the DE? I found ADBOBJECTS(), which goes all the way back to the DBC, which I probably will use to modify the updaterows method and use your code below (at least then it will be in the order I added them to the DBC), but couldn't find one for the DE. Interesting.....

PS, thanks for the tips on the other question. I'm going to look at those examples today!

Laurisa Watkins
Seattle Parks Dept.

>Laurisa, the Save button works through your DataEnvironment in the same order as each cursor was added to the DE. If you open your DE and click on each table, you will see 'Cursor1', 'Cursor2', etc. This is the order of the save. You can remove all the cursors from the DE and add them back in turn, or you can make a method (or even an application object method or a class you drop on a form) which orders the tables correctly.
>
>You could design a method that includes ALL your tables, skipping tables not in use with
>

>if used('ThisTable')
>   nRet=tableupdate(1, 'ThisTable')
>endif
>

>and attach this code to each form.
>
>HTH
>Barbara