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