I realize you were specifically asking for vfp6 alternatives, so prbably have compelling (budgetary) reason not to port to vfp9 and use the newer features. In vfp6 we had to scrap transactions because we ran headlong into issues involving Chr(0) inserted by vfp in existing records although the user code was fine. Backends: vfp shared tables and DB2 depending on customer pref.

So if transaction is conditio sine qua non, perhaps reconsider/recalculate.

my 0.22€
thomas

>Yuck, yuck, yuck. Why do things have to be so crappy? I inherited an application. It's using a mix of SPT and Remote Views. I wanted to use a SQL Server transaction. Nope. The application has one main connection. The views get different connection numbers. I tried to make them share, but that began to cause problems.
>
>I made a bunch of queries to extract data as the views did. I then used the app's built in "SPT-based create an execute an sql insert command". I also made update queries. So, I excluded views. The transaction worked fine. Views and parameterized views have mutated over the years, and were finally replaced with cursor adaptors. But I'm stuck in 6 for the time being.
>
>Views are basically a name given to a bit of SQL code.
>
>I am trying to think through some form of alternative to views, that I can implement easily going forward.
>
>There is the make_updateable (sp) bit of code. That should allow for all inserts and updates. Does it include allowing 2 users who did not touch the same fields to save? Does it also respect the buffer mode? As the user moves off a record, it can update/insert?
>
>To requery this hypothetical view, a safe-select can be used. It can first update any changes in the local cursor from the remote. It can then append all the records not in the local cursor (provided the primary keys are easily obtained).
>
>Once this alternate view is opened, I may want to change the parameters.
>
>Is there an existing VFP6 data object class that does all of the above?