>>>I don't. We are in the process here of determining if we want to go this way or not. If so, we know we'll probably have to write our own. Rick Strahl may have something on his web site. Erik Moore (who hangs out regularly) wrote one but I don't know if its public domain. He may jump in here with his $0.02.
>>>
>>
>>It's not too difficult to write a basic routine that parses a basic UpdateGram to generate a SQL statement, or actually performs the updates. The problem is with full support of the Updategram spec. There are lots of contingencies to handle, and coding for all of them is going to be tedious. Also, since a client side cursor may not have the same name as the server side table, so if you use VFP's XMLUpdateGram function, some translation mechanism is needed. For SQL, Mapping Schemas were designed to handle this, but that a hole can of worms I didn't want to put the time into providing for with my XMLTableUPdate. All this gets exponentially more complicated if the update routine has to handle transactional updates. These issues, BTW, are why VFP's XMLTableUpdate didn't make it in to VFP 7.
>>
>>BTW, I never released my function for Public Domain because I never polished it enough want to put my name on it, and I don't plan to.
>>
>>After spending a bunch of time with UpdateGrams, I came to the conclusion that they have no place in n-tier development. The reason is that an UpdateGram is only required to carry the information needed to make the change, and does not carry an entire representation of the record. If the Updategram is generated on the client and passed to the server, the server has no easy way to make record level validations for the record in question, because only part of the record is represented in the XML. To make a record level validation, the server process would first have to query the database for the current state of the record, and merge that with the Updategram to get a picture of what the new state of the record is. This need immediately doubles the processing resources needed to make a simple update, and for little gain.
>>
>>If the validation can occur on the client, however, and the server process is only in place to apply the changes to the data, then Updategrams might be the way to go, but then you're not doing n-tier, you're doing Client Server.
>>
>>My current strategy is to take each record that needs to be updated, do SCATTER NAME on it, and use wwXML::ObjectToXML to create a document with a schema, and pass that record (in XML format) to the server for validation and processing. The server does an wwXML::XMLToObject, performs field and record validations, and depending on the backend, either maps Object properties to parameters in a SQL stored procedure, or locates the VFP record and performs a GATHER NAME to complete the update.
>>
>>My $.02.
>
>Erik,
>
>Do you know of any sources (articles, white papers, books) regarding this?

Updategrams? Or n-tier design?

The only Updategram information I know of is the spec from MS. You can find it by going to MSDN and searching on Updategram.

There are lots of articles and books on n-tier design, but none, of course, on the specific stratey I described. Doug Hennig had an n-tier article in FoxTalk a while back, it described using ADO for the same purposes. The COMCodeBook documentation describes a lot of the principles, but might be a little much for a beginner.