>Hi Srdjan,
>
>the syntax possible due to session usable as standalone clearly is better than linking forms and manipulating datasessionID at runtime - no argument.
>But if I compare the twistings under FPD 2.x/FPW to get minimal isolation of table data from "undecided user input"
>- most of the time using scatter to array for each record used as form-basis - as to not disturb others in multiuser apps,
>with
>the whole bundle of buffered input, isolated/encapsulated data sessions selectable via datasessionID, tableupdate, tablerevert, oldval, currentval, getnextmodified, get/setfieldstate and the necessary cursorget/setprop
>
>the new way was so far ahead of the old paradigma... Re: you later comment about well written DOS prgs:
>I had built most of my stuff based on an approach described in 2 similar books (DOS+FPW) based on having "buffered screens" via store to array, so that all edits were buffered until "save" was triggered, even for child and grandchild records.
>Lots of checks and acopy if step was done in parent table to show edited but unsaved data...
>The first forms I moved for at least 3 month ran under belt-and-suspenders approach: old functionality was kept as a sanity check to verify that the new stuff really did what docs described - not really "magic", but incredibly smart approach that at first I did not believe it was error proof. Removing the array based stuff felt GREAT. That is why I try to tell the xSharpies that this area is the true DNA of vfp, as it enabled the other goodies like remote views first, cursoradapter later, to give a locally cached subset of remote data to play with and then decide if saving made sense, needed further tweaking via full blown SQL if one wanted or should be thrown away. Most of the other stuff (data binding, mapping records to memory structures/arrays/objects) was doable (often less elegant/more wordy) in other languages, but the local buffered cursor or table for me is/was the secret sauce keeping me using it >>>>
>>

As extra added bonus to those of us who fully implemented buffering and save all / nothing approach next to pretty robust referential integrity, comes added bonus of much less (close to 0!) table corruption when talking about shared dbc tables.

I mentioned it several times around here, that so far I did not experience any SMB2/oplocks issue or any other type corruption (knock on wood!) even after upgrading all data servers to latest and greatest versions.
My theory (without proof) is that the same thing that kept corruption down back in DOS era of still unstable networks, namely well written apps (scenarios as you described) are keeping corruption down even today. That time well written app was battling cheap routers, bad hubs, unstable electricity and what not, today they are battling mostly smb2/oplocks with more or less the same success.

So buffering/transactions on DBC based tables for X# ... yes please! :-))
Just hope is not to tall of a order..

Rgds++
Sergio