AFAIK, Making an SPT updatable, gets you the same properties of a view, except the ones that have to do aquiring the data.

So buffering, transactions, batchupdate count should work as with views

Walter,


>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?