>Hi Walter
>
>>>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.
>
>>But the real question is, do you know if there is any truth to the idea that the transaction is "safe" since all tables are in a single DBC?
>
>It is also 'safe' if the tables are accross different DBCs. It really does not matter. If wrapping updates in mutliple DBCs into one transaction, and the transactions fails and you do a rollback all changes are rolled back.
>
>And of course a VFP transaction is not really safe compared to the ACID properties found in SQL server. If during the transaction the power goes off, you don't know what you'll end up with.
>
>>>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.
>
>>The whole point of this second DBC is to have it on the local machine along with the exe.
>
>Why not including it into the executable itself?
>

I might be mistaken - but I don't think VFP lets you include dbc's in the .exe - plus who whats to recompile everytime you change a table structure and a view?
What you can do is include it in the setup, then when the application starts have it run something (like a stonefield process) to see if any of the views need to be updated. This is something else I've done in the past.

>Walter,