>>>>>No great biggie here.
>>>>>
>>>>>I'm replacing a system from its FPD26 days, and the tables still need to be used by the old system. There are cases where there's a 1-m reln. so as I create a certain rec I need to create < = 3 related table recs. I'm afraid of crashes during this process, or during my programmed cascaded delete
>>>>>
>>>>>I was wondering if anyone knew of, or has developed a clever way around the fact that you can't use transactions here, as the old tables aren't part of a dbc. The only way I can think of is to keep track of newly created recs and deleting them if, say, a related TableUpdate() fails, or say, using RECALL when part of a cascaded delete fails.
>>>>>
>>>>>'ppreciate it
>>>>>
>>>>>Terry
>>>>
>>>>Terry,
>>>>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.
>
>It's not the way I designed the system (if I could see the design I'd be spinning in my grave) and I'm stuck with it.

I didn't say add tables. I said create views for the tables. You can create a dbc and its views programmatically on the fly.
Cetin