>Where do you see it failing?

Craig, you are saying it will work. I asked you if you tested it? Rather than asnwering the question, you answer my question with a question. FWIW, I am on record with respect to where it can fail. My question to you is did you factor any of that in? Have you ever implemented anything like this.

Probabably best for you to look at my response to the originator of this thread....

Again, it is very sad to see how RV's have crippled the thinking process of folks with respect to what is truly required for C/S development. RV's represent an inccomplete black-box around what is in reality, a very complex process.

Remember, the originator of the thread asked if it was the proper/best way to handle Tx's with SQL Server.

The question WAS NOT whether it would work.. Lots of things work in the world. Whether they represent the correct approach or the best/opimal way is another issue all-together. Again, I hark back to my favorite saying: English is a precise language...< s >...

You know, there is a reason why the ability exists to handle Tx's manually. Invariably, if given the choice between having something done automatically or having something done manually - under my control, I will choose the latter in most cases. Any exceptions to this rule? Sure. Buffering stands out as a big one. It works very well. Tx processing however, is another animal all together. The bottom line is that it is not a trivial matter. SQL Server has its own Tx processing capabilities - and it is best to make direct use of those facilities...

Begin/End Transaction and Rollback is nice for VFP data. However, it falls short of the mark for what is required in SQL Server...

Quite frankly, the best way is to encapsulate the Tx processing in the context of a stored procedure. However, this then disallows the use of RV's. Again, I don't see the use of RV's as a best practice - too many pitfalls - too much of an incomplete implementation. Again, I throw out the invitation to anybody, including you that would like to debate this topic. Of everyone, Bob Archer did the best, but in the end, could not adaquately defend the shortcomings of RV's.

Lest it be said that I have no beef with the VFP cursor model. SPT works fine. It is the RV wrapper that sits on top of SPT that sucks. If you use SPT, you need to do all of this stuff manually anyway. How do you think this stuff worked before RV's hit the scene?

For very simple implementations, will the sole use of RV's suffice? Probably. However, I have yet to see a real simple implementation. Rather, everything is moderately complex. The developer is too cut-off from the granularity of control required through the sole use of RV's. To counter-act this problem, as much as you can, you need to share the connection handle and make use functions like SQLCommit, SQLRollback, etc....

Just my 2-cents....borne of too much experience....

FWIW, I made many of the same conclusions that have been made up here and elseware. A funny thing happend when I actually started to use the SQL Server product... I learned how it really works... From that, I learned a valuable lesson. Sure, the theory says that you can make sole use of RV's and nothing more.. The reality specifies otherwise...


>>>>>This will work.
>>
>>I would not be too sure about that....
>>
>>Have you really tested this????
>>
>>
>