>> but to demonstrate that client storage strategy is completely independent of the middle-tier input/output format...
>
>bravo Erik, excellent strategy. Any downsides to it that perhaps caused you a little unexpected or extra work with reworking this into your own framework?

No, not really. Fortunately, my previous framework already had all Query and Save operations wrapped in objects, so making the change to the client framework was as simple as replacing a few key framework objects. Virtually no form specific code needs to change at all.

I was really looking forward to making use of XML Updategrams to send updates from the client to the server, until I realized that middle tier validation would get extremely tricky if I only had the parts of the record that changed, so I resorted to sending the whole record in XML.

I had to write a considerable amount of XML parsing and construction code, but I'm nearly finished with that, and once I am, I should never have to even see XML again, because the framework will do all the translation for me.

What's cool about this is that the middle-tier interfaces the front-end through WinInet and WWWC, so client applications can run _anywhere_ as long as they have internet access. I am not using DCOM anywhere, everything is HTTP (No DCOM permissions headaches, no OLEDB provider or ODBC driver to install and configure on the client).

In case you were about to ask, I have security worked out in my head, but it's not implemented yet. I will be able to flip a switch and have all internet requests run through SSL, and ensure that each server process invoked is invoked by an authorized client.