>>
On the backend, a component takes care of reading the message and traversing the recordset to make the inserts.
<<

Explain this step to me. Tell me exactly how you accomplish this. If you are using the Update/UpdateBatch methods of the recordset, there is no need to "traverse" the recordset. If you are using some other means of updating, say taking the data from the shaped recordset and marshaling it a command object, then you have just made my point.

As far as MSMQ is concerned, I don't see that as being relevant to the issue.

Also, I would be interested in the metrics of your app.


Also, please explain this statement:

<<
You have a parent-child relationship that is all on the client side at the time the data is collected.
<<

Is this new data? Or, is this existing data? Please clarify...


Thanks,

< JVP >


>OK, I'll just give an example where shaped recordsets are a solution (and they work too). You have a parent-child relationship that is all on the client side at the time the data is collected. You want to improve your chances of data delivery on a three-tier architecture and its immediacy is not particularly important. You bring in MSMQ, populate a shape recordset in the client and off it goes. On the backend, a component takes care of reading the message and traversing the recordset to make the inserts.
>
>This is an application we have in production here. It was built by a coworker, but we used to discuss our projects on a regular basis.