>Hi. I guess you can say I'm taking a survey. I would like to hear from those of you who are actively using XML, especially where VFP is involved. What are you doing with it? Why is it better for your situation than any alternatives, especially ADO?
>
>I know that's a very broad question. You can start with general answers, if you like, and maybe we'll get more specific later. Thanks.

Kelly,

I'm currently putting together an intranet application that takes 11 existing stand-alone VFP installations and replicates (in real-time) all data to a central SQL-Server, as well as doing a "store-and-forward" action on data entered at "point A" and destined for "point B." This will be done over a WAN with low bandwidth, linking computers spread across several miles and facilities.

The short answer for "why XML and SQL" is they are easy to implement and I knew they would be readily accepted by the client when considering my proposal. I am an outside developer brought in my one of their sales reps (a friend of mine) when their internal IS folks told him "it can't be done." SQL-Server and XML are perceived as "non-proprietary" and are comparatively non-threatening to internal IS staffers who could try to nix the project before it got started. It would make them look foolish trying to stop a project that was over their heads because they weren't willing to learn and support two of the most widely accepted technologies in use today.

SQL data allows ubiquitous data access from the client's query tool of choice, while allowing us to grant read-only access to prevent "accidental" data corruption by end users. Why XML? I had to use *something* as a transport protocol over HTTP, and the quantity of data being transmitted is small enough that XML's "bloat" presents no real problems. Also, since this is an intranet, passing XML as clear text keeps us from having to sweet-talk every firewall administrator in every facility to allow our binary packets to get through. While it's important that the data be kept accurate, it is not considered "sensitive" in nature, so encryption is not necessary. I have used ADO in the past, and would not use it again except in very controlled situations. XML is "just data," whereas ADO is data plus query logic and other implementation stuff. ADO is sensitive to not only the operating system, but to the installed MDAC components, which can be altered when users (or administrators) update MS Office, IE, or other tools. In the past, that has made my "data" a moving compatibility target, with surprise support calls saying "my app doesn't work any more" when someone installed a Service Pack or other seemingly harmless update. While SQL-Server OLE-DB drivers can also be trashed by installing other software (yes, I've had that happen, too), it has not happened nearly as often as ADO out-of-date or installed-out-of-sequence problems have reared their heads. So with XML, there's less to go wrong in areas over which I have no control.

If you need more info, I'll expound more. Hope this is what you're looking for.