>>>>>If the old system would continue to use them then you already would access via a view, no? There is a dbc IOW.
>>>>>Cetin
>>>>
>>>>Sorry, Cetin, I don't follow you. I don't access the tables as views - just as tables. Non-dbc tables don't support views do they, or am I missing something here.
>>>>
>>>>Whatever, how can I use xactions?
>>>
>>>What I'm saying is simple. Create a dbc and views for tables.
>>>Cetin
>>
>>But if I create a dbc and add these tables to it, won't they then be "tainted" with VFP7 properties, such that the FPD26 appplication will no longer recognise them (being of their future)?
>>
>>Also, because of the legacy of the way the old system works, there's a different folder for each of a series of transport authorities. Each set of tables would have to be assigned to its own dbc, i.e. a new dbc created and populated. Then, there's the problem that certain tables, for certain authorities, do not have the same structure as others, e.g. a key code may be c(2) for one and c(4) for another.
>
>I'm not sure if you're getting it clear from what Cetin is saying. You can have a dbc with views only, and the underlying tables for those views can be your free tables.

I think I twigged last night when I thought back on't. Do you/does he mean views that are like, say:

"Select * from X into ViewName"

i.e. the view becomes just a virtual copy of the table, with SendSQLUpdates?

>
>The trouble may be in the update criteria - if your free tables don't have proper PKs, you may have to update them using updated or updatable fields, which is a lot heavier in terms of the WHERE clause in the update statement (generated behind the scenes).
>
>And then if you're using views, you should be able to wrap your processing in a transaction.