Hi Walter,

I've been doing this as well, but recently I've run into a problem. It seems to only happen on some Windows XP pro boxes. config file brings tmpfiles to local \temp. Data files on server, EXE running locally. views dbc compiled in.

On some boxes a view with indexes ( created from metadata in VFE ) will crash on opening. Excluding views dbc solves the problem. Can't reproduce it on any of my dev boxes and on half my client boxes ( even those that shared a common data store on the network. ) Permissions are identical. My only suspicion is it has something to do with which updates are installed though I can't track that.

Have you seen anything like this?


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