Hi mike,

I've been using this strategy for a couple of years now. The views are stored in a seperate DBC which is included into the project. The views point to tables in the other database.

This all work very well. For one project I've wrapped several databases into one transaction and it all works fine. However you cannot wrap free tables into a transaction.


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

Yes it is. In fact my personal framework is based on this priciple.

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

Not sure what you're saying here

>So the transaction could be managing updates in a single DBC.

Nope, multiple DBC should work well.


One tip: If you want to speed up your views, make sure that they either are readonly or opened exclusively. This will cache the DBC on your workstation and will speed up opening and requerying of your views.


Walter,