I just tested a similar scenario. In my testing, a ROLLBACK does not work if a tableupdate fails on a child table. Record added to parent table was added even though transaction failed and ROLLBACK was issued.



>OK I shouldn't be lazy to provide code:)
>

>Local lcFox2xPath, lcConnName
>lcDBCName = "myFox2xLink"
>lcFox2xPath = 'c:\fpd26\tutorial'
>lcConnName = "myFox2xLinker"
>Create Database (m.lcDBCName)
>Create2xConn(m.lcFox2xPath,m.lcConnName)
>myViewMaker('v_customer','cno',m.lcFox2xPath,'customer',m.lcConnName)
>
>Use v_customer
>CursorSetProp("Buffering",5,'v_customer')
>CursorSetProp("BatchUpdateCount",10,'v_customer')
>
>Insert Into v_customer (cno) Values ("TRAN1")
>Insert Into v_customer (cno) Values ("TRAN2")
>Insert Into v_customer (cno) Values ("TRAN3")
>Insert Into v_customer (cno) Values ("TRAN4")
>
>If !Tableupdate(2,.T.,'v_customer') && should fail
>  Sqlrollback(CursorGetProp("ConnectHandle",'v_customer'))
>Endif
>Select * From (Addbs(m.lcFox2xPath)+'customer')
>Use In 'customer'
>
>Select v_customer
>Scatter Memvar Memo Blank
>For ix = 5 To 9
>  m.cno = "TR"+Padl(m.ix,2,'_')
>  Insert Into v_customer From Memvar
>Endfor
>
>If Tableupdate(2,.T.,'v_customer') && shoudl succeed
>  Sqlcommit(CursorGetProp("ConnectHandle",'v_customer'))
>Endif
>
>Select * From (Addbs(m.lcFox2xPath)+'customer')
>Use In 'customer'
>
>Close Databases All
>Erase (m.lcDBCName+'.*')
>
>Procedure Create2xConn(tcDataPath,tcConnName)
>  Local lcConStr
>  lcConnStr = 'Driver={Microsoft Visual FoxPro Driver};'+;
>    'SourceDB='+Addbs(m.tcDataPath)+';SourceType=DBF;Exclusive=No'
>
>  Execscript(Textmerge("CREATE CONNECTION '<<m.tcConnName>>' CONNSTRING '<<m.lcConnStr>>'"))
>
>  DBSetProp(m.tcConnName, 'Connection', 'Asynchronous', .F.)
>  DBSetProp(m.tcConnName, 'Connection', 'BatchMode', .T.)
>  DBSetProp(m.tcConnName, 'Connection', 'ConnectTimeOut', 15)
>  DBSetProp(m.tcConnName, 'Connection', 'DispWarnings', .F.)
>  DBSetProp(m.tcConnName, 'Connection', 'IdleTimeOut', 0)
>  DBSetProp(m.tcConnName, 'Connection', 'QueryTimeOut', 0)
>  DBSetProp(m.tcConnName, 'Connection', 'Transactions', 2)
>  DBSetProp(m.tcConnName, 'Connection', 'Database', '')
>Endproc
>
>Procedure myViewMaker
>  Lparameters tcViewName, tcKeyField, tcPath, tcTableName,tcConnectionName
>
>  Execscript(Textmerge(;
>    "Create Sql View '<<m.tcViewName>>' "+;
>    " remote connect '<<m.tcConnectionName>>'"+;
>    " As"+;
>    " Select * From ('<<Addbs(m.tcPath) + m.tcTableName>>')"))
>
>  DBSetProp(m.tcViewName, 'View', 'WhereType', 3)
>  DBSetProp(m.tcViewName, 'View', 'SendUpdates', .T.)
>  DBSetProp(m.tcViewName, 'View', 'Tables', m.tcTableName)
>
>  Use (Addbs(m.tcPath) + m.tcTableName) In 0 Again Alias __getfields
>  Afields(aFieldList, '__getFields')
>  Use In '__getFields'
>
>  For ix=1 To Alen(aFieldList,1)
>    DBSetProp(m.tcViewName+'.'+aFieldList[m.ix,1], 'Field', 'KeyField', ;
>      Upper(aFieldList[m.ix,1])==Upper(m.tcKeyField))
>    DBSetProp(m.tcViewName+'.'+aFieldList[m.ix,1], 'Field', 'Updatable', .T.)
>    DBSetProp(m.tcViewName+'.'+aFieldList[m.ix,1], 'Field', 'UpdateName', ;
>       m.tcTableName+'.'+aFieldList[m.ix,1])
>    DBSetProp(m.tcViewName+'.'+aFieldList[m.ix,1], 'Field', 'DataType', ;
>      TEXTMERGE( "<<aFieldList[m.ix,2]>>(<<aFieldList[m.ix,3]>>" )+;
>      IIF(aFieldList[m.ix,4] > 0, Textmerge(",<<aFieldList[m.ix,4]>>)"), ')' ))
>  Endfor
>
>Endproc
>

>Cetin
>
>>Nah, they can't, afaik. That's why I was looking for something that might simulate them.
>>
>>>Unfortunately, I don't believe that free tables can participate in a transaction in VFP 7. That feature was added in VFP 9.
>>>
>>>I tried to do something to simulate transactions for free tables in VFP 6 for a similar scenario and was never able to come up with a satisfactory answer.
>>>
>>>
>>>>>>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?