Daniel,
Have thought about using parameterized views and then update-SQL.

>I am having trouble with buffered data being committed to disk before I issue a tableupdate() command. I pull up a form that allows the user to edit a single record (by choosing that record from a grid on another form). This form runs in a private data session and has optimistic record locking enabled. After the user clicks the "Save" button but before I actually issue a "tableupdate()" or "end transaction" I call a routine that steps through each control on my form, finds all the controls with control sources, and records any differences between it's current value and the oldval() of the control source for that control. The routine compiles a list of changes that looks something like this: "customer.lastname changed from Smith to Johnson" etc... This data is then inserted into an audit table (assuming that the tableupdate() succeeds) The problem is that by the time that I get to the routine, the control.value and oldval(control.controlsource) are the same, even though I know that they
>have actually changed. Because the form only pulls up a single record and there is no facility for moving the record pointer from within this modal form, I know that the data isn't being commited by the record pointer being moved off of the record.
>
>The really strange thing is that if I pull up the 'data session' window and browse the table as I update it through the form, the routine recognizes the oldval()'s as being different and accurately reports them to the audit table. I REALLY don't understand why this is happening.
>
>Does anyone know why this is happening? Or perhaps, there is a better way of accomplishing this task while remaining independant of the table and form structure.