Cetin,

This example is exactly what I'm looking for. My only question is how to make this work
with multiple tables, say as in a JOIN?

If I have 2 or 3 tables JOINed together, and make changes to the resulting dataset,
how do I then propogate the changes back to all base tables?

Thanks

Kevin




>Yes and no. Depends on version. Under VFP9 you have the luxury doing this with XMLAdpater class. The diffgram I pasted is from VFP7. Here is a sample for VFP9 that both creates the diffgram (might be your COM1) and updates from XML diffgram (might be your COM2):
>

>LOCAL lcDiffXML
>lcDiffXML = GetDiffGram() && COM1 creates diff.
>UpdateFromDiffgram(m.lcDiffXML) && COM2 gets XML
>
>
>PROCEDURE GetDiffGram
>USE _samples+"\data\customer"
>CURSORSETPROP("Buffering",5,'customer')
>BROWSE TITLE "Modify on site 1"
>
>* Create diffgram xml
>LOCAL lcChanges, oAdapter
>oAdapter = CREATEOBJECT('xmlAdapter')
>oAdapter.AddTableSchema('customer')
>oAdapter.IsDiffgram = .T.
>oAdapter.ToXML('lcChanges','',.f.,.t.,.t.)
>* Closing data just for sampling
>USE IN 'customer'
>RETURN m.lcChanges
>
>PROCEDURE UpdateFromDiffgram(tcDiffGram)
>LOCAL oAdapter
>* just for sampling using a different alias
>USE _samples+'data\customer' ALIAS myCustomer
>* we don't want to save when we are sampling only
>CURSORSETPROP("Buffering",5,'myCustomer')
>BROWSE TITLE 'Before applying diffgram'
>
>oAdapter = CREATEOBJECT('xmlAdapter')
>oAdapter.LoadXML(m.tcDiffGram,.f.)
>oAdapter.Tables(1).Alias = 'myCustomer'
>oAdapter.Tables(1).ApplyDiffgram()
>BROWSE TITLE 'After applying diffgram'
>

Too much hardcoding in there but this is a sample:)
>PS: AFAIK you also work with .Net and you would like to know XMLAdapter is friendly with .Net datasets and diffgrams (also VFPOLEDB have as added support).
>Cetin
>
>>Do I understand that I must store the changes back to the database myself? How is this
>>done? There could be any number of records and field changed. Is there any way to do
>>this automatically?
>>
>>
>>
>>>XmlUpdateGram() function creates an updategram (needs multilocks and buffering). That is it only includes updated/inserted/deleted records as updgram:before and after records. Suppose you updated customer table and changed company field, deleted ANATR and inserted NEWCUS. XmlUpdateGram('customer') produces an output like:
>>>

>>><?xml version = "1.0" encoding="Windows-1252" standalone="yes"?>
>>><root xmlns:updg="urn:schemas-microsoft-com:xml-updategram">
>>>	<updg:sync>
>>>		<updg:before>
>>>			<customer>
>>>				<cust_id>ALFKI</cust_id>
>>>				<company>Alfreds Futterkiste</company>
>>>* other fields here
>>>			</customer>
>>>		</updg:before>
>>>		<updg:after>
>>>			<customer>
>>>				<cust_id>ALFKI</cust_id>
>>>				<company>Alfreds Futterkiste-Updated</company>
>>>* other fields here
>>>			</customer>
>>>		</updg:after>
>>>		<updg:before>
>>>			<customer>
>>>* all fields here - unmodified
>>>			</customer>
>>>		</updg:before>
>>>		<updg:after/>
>>>		<updg:before/>
>>>		<updg:after>
>>>			<customer>
>>>				<cust_id>NEWCUS</cust_id>
>>>* other fields here
>>>			</customer>
>>>		</updg:after>
>>>	</updg:sync>
>>></root>
>>>

Instead of receiving the whole table diffgram approach only gets 'differences' IOW. On receving side you have to process this yourself however (ie: XMLDocument). VFP9 CA and XMLAdapter might help you to work with them in an easier way. Check www.prenia.com for samples.
>>>Cetin
>>>
>>>
>>>>The reason I'm using COM is because I will need to update the
>>>>application piece by piece. I don't want everything compiled
>>>>into one big EXE.
>>>>
>>>>Can you elaborate on the DiffGram option?
>>>>
>>>>
>>>>
>>>>>Hmm that in turn would bring up other questions. Ways to go are more than one and which one to choose depends. ie: One scenario:
>>>>>
>>>>>Instead of CursorToXml and XmlTocursor you might choose ADO and pass an ADO recordset instead.
>>>>>Another one is to pass a diffgram instead of all rows using CursorToXML and XMLToCursor.
>>>>>Yet another one might be passing just an array of records that are updated/added/deleted with flags.
>>>>>
>>>>>Actually first I would think of "do I really want to talk between COM objects or even do I want a single COM object in my application" - sounds like I don't like COM objects:) Really I don't, too much problems with them for me (call it DLL hell, security etc etc).
>>>>>
>>>>>If one of them can connect to data why would other one cannot and a need for 2 evils?
>>>>>Cetin
>>>>>
>>>>>>Thanks. This brings up another question.
>>>>>>
>>>>>>I want to use CURSORTOXML() and XMLTOCURSOR() to pass data to and
>>>>>>from COM objects.
>>>>>>
>>>>>>Once I make changes to data and convert it to XML, and after I use
>>>>>>XMLTOCURSOR() to create a cursor, whats the best way to update the
>>>>>>database?
>>>>>>
>>>>>>I am using a VFP database now, with possible plans later to convert
>>>>>>to SQL Server.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>For the 'nOutputFormat', 'nFlags', 'cSchemaName', 'cSchemaLocation', and 'cNameSpace'
>>>>>>>>parameters, are there any standards as far as what settings I should use?
>>>>>>>>
>>>>>>>>I am only using the command to pass data back & forth between COM objects.
>>>>>>>
>>>>>>>If there were standards there wouldn't be flags;)
>>>>>>>nOutputFormat: 2 or 3 are my favorites. More compact.
>>>>>>>nFlags: 1 to make it compact.
>>>>>>>For others it depends. Probably "1" inline schema would be good.
>>>>>>>
>>>>>>>With these settings:
>>>>>>>CursorToXml('myAlias','myMemvar',2,1,0,"1")
>>>>>>>would create a compact XML with inline schema and store in m.myMemvar and IMHO is good for your need.
>>>>>>>Cetin