While I see your reasoning for the remote views, you are probably taking a performance hit versus local views, no?

>Quite interesting, this is something I hadn't thought of.
>I don't know if this will help any - but this is what I've been doing lately....
>One DBC for the tables, and another one for the views - however I made all the views remote views, not local views. This was done for 2 reasons. 1) If the tables are designed properly, then updating to SQL server is just a matter of changing a connection string in the view's DBC, and 2) Remote views don't open the tables like a local view does. As for the transacations - I'm not quite sure how that works in this situation - however I am using the getfldstate and that does seem to work. I'm using tableupdate and tablerevert, but haven't wrapped these updates within a transaction (which is something I was planning on doing one of these days.) If I get a chance later today I'll playing around with it and eyeball the behavior.
>
>>Hi all
>>
>>Back when I used views I began using one DBC for views and another for tables. The premise was that the contention caused by two users accessing a single DBC for a single view would be eliminated. This worked very well.
>>
>>A warning from Drew Speedie has me thinking this situation through. Again, to me this is mostly academic now, but here goes. The warning is that transactions are not supported across multiple DBCs.
>>
>>If a view is in DBCa and a table is in DBCb, when I alter the record(s) in the view, begin a transaction, issue a tableupdate (on the view of course) and something goes wrong, I rollback the transaction. Is the transaction spanning multiple DBCs? I think not.
>>
>>I'm guessing here, but the transaction is wrapping updates. Data is moved from the view to the table. If the transaction fails, only the changes made to the table must be undone. I doubt the view itself is updated. The getfldstate flags are certainly updated, but I'm guessing they are not part of the cursor. Even so, that cursor is exclusive and any reverts should work.
>>
>>So the transaction could be managing updates in a single DBC.
>>
>>Anyone know for sure?