>My suggestion is for you to check out Dataclass and download the docs that spec out the architecture. That will clear up a lot of issues for you.

I will check that out. It's been on my todo list for quite some time.

However, from a VFP perspective, without incorporating another product at this time... to use SPs would I need to do what I outlined?

I've asked this question before, not to you, and I never get a straight answer. I'm pointed to simplistic examples of a single table, single row update, which I understand. It's when you go to multiple tables, multiple rows that I get tripped up in getting a handle on this. Thanks!


>Remember, SP's are nothing more than SQL stored on the back-end. Whether you choose SPT, which RV's are built upon or SP, you can achieve the same results. OF course, client-side rendered SQL vs. SP's each have their respective pros and cons. That is why the issue is not RV's vs. SP's. Rather, it is RV's vs. SPT. Whether you go on to use SP's or not is another issue. I will tell you that I have dealt with data problems with SP's that many here would believe could only be accomplished in VFP.
>
>As far as the domain you describe below, change the names around and I don't see a distinctly new problem that has not already been solved.
>
>
>>It's been very interesting to read. One part of this issue that I've been trying to get a good handle on is this: If you decide to use SPs as your only access method, how do you handle, for example, the creation of a Medical Claim and all its related data:
>>
>>Patient Demographics
>>Patient Insurance Coverage
>>Claim Header Information
>>Claim Service Line Information
>>
>>This could be Inserts/Updates to 4 tables and in the case of the Service Lines, multiple records, let's say 10 records. Would you create 4 different SPs (one for each table) and wrap the 13 calls in a transaction? 13 SqlExecs()?
>>
>>This is at the heart of why I still use RVs, BTW. I start the transaction and then TableUpdate() each View.
>>
>>TIA,