Hi Jeff,

No, I haven't built an UPDATEGRAM parser but I am using them extensively with SQL Server and the SQLXML 3.0 Beta. They seem to work as advertised and the learning curve was not too steep. You might also want to check out the use of mapping schemas, they handle all the field mapping and relations.

Here's a sample procedure clipped from my data handling tier:

PROCEDURE Delete(tcID AS String) AS String
	LOCAL lcSchema,lcGram
	WITH THIS
		* Build the updategram header
		lcSchema = .cBasePath+.cSchemaFile
		lcGram = [<ROOT xmlns:updg="urn:schemas-microsoft-com:xml-updategram">]
		lcGram = lcGram+[<updg:sync mapping-schema="]+lcSchema+[">]
		lcGram = lcGram+[<updg:before>]
		* Add the pkid of the row to be deleted
		lcGram = lcGram+[<]+.cClassName+[ pkid="]+tcID+["/>]
		lcGram = lcGram+[</updg:before>]
		lcGram = lcGram+[<updg:after>]
		lcGram = lcGram+[</updg:after></updg:sync></ROOT>]
		lcRetVal = .SendUpdate(lcGram)
	ENDWITH
	RETURN lcRetVal
ENDPROC

The Update and Insert methods are a little more complicated but as you can see, most of the effor is in building the strings to form the XML message. The SendUpdate() procedure has all the ADO stuff that moves the UPDATEGRAM to the SQL Server. I'm also using the SQLXMLOLEDB provider.

Happy learning!