It's still bad architecture, IMHO.

Booth is a proponent of always table buffering......perhaps there is a method to his madness.



>>IMHO NEVER. I can't think of one.
>>
>>>What are the circumstance when it is prudent to use double buffering and when perhpas not?
>
>NEVER say NEVER, John. ;-)
>
>Actually double buffering comes in handy in cases where you want to perform SQL statements on row buffered data. Because SQL Selects open the source again, it doesn't see any changes you have made to the data. You can issue a tableupdate on the view writing the data to the underlying tables. Because those tables are buffered, the data hasn't been written to the disk yet. You can perform the SQL stuff on the views and Tablerevert when done.
>
>I don't use this technique because I use table buffering so I can move the record pointer anywhere I want and not tableupdate anything. Because I know SQL selects don't work on buffered data, I use other means to do what I need done.