Thomas,

the applications are huge....it took several man-years to create them (I was not involved in the initial creation). I will take your advice on creating a routine outside fpw26 to read the initial xml-file. As long as the xml is processed into a format that fwp26 can understand (dbf, xls, sdf) I will be able to find work-arounds....

You´re absolutely correct about the waste of resources...but i´m just the hired gun. I create VFP apps and com-objects for other customers but this customer has this huge fpw26 app. They are in the process of re-designing it and to build it with java but progress is slow and they need someone to keep these programs up and running because it is unlikely they will disappear in the next two to three (!) years.

Thanks for your advice,

Ron

>Hi Ranjan,
>
>>Nowadays everyone wants to use xml for interfacing purposes.
>> Reading them...is. I need to implement this (in FPW26) not because I like >to.....if you have any suggestions let me know ;-)
>
>XML can be used for quite a lot of things <g>...
>In interfacing I guess we are *not* talking about serializing objects to pass among tiers but more on the "database aspect" of xml to describe a "dataset" or someting similar.
>
>If I am correct, you should be able to create an "adapter" to write out the respective tables or array's to be used further on in your FPW-app.
>
>From a technical point of view this "adapter" doesn't have to be built in FPW, all it needs is the ability to write out a datastructure FPW (the legacy app) can work with - perhaps with some added inter-process communication like "I wrote the n files named xxx into this directory yyy" and "I'm done".
>
>So why insist on having this adapter written in FPW ? Implement it either in the language that creates the XML via ODBC, or (the thing I would do) create it in VFP and start/call this process from the legacy App.
>
>If development is time critical, build a process communication between the legacy app still in FPW and the new component in VFP via DDE with a security backdrop of file based semaphores.
>
>Since there is a move to overhaul the legacy system, I'ld usually argument for quick-porting the legacy app to VFP. This will not give you a OOP version, but you can re-build while running the system, which is necessary if it is a production system with a high change rate, such as the app I'm mostly working on - car insurance.
>
>It still depends a lot on how the FPW-system is written and how large the app is - the more of a dog in FPW, the less of a shining beauty in VFP.
>
>In my experience the conversion to VFP helps to clean up quite a bit, but such a move must be supported by managment as a way to lessen the foreseeable update cost of the running system.
>
>To implement XML-transformation in FPW doesn't seem like a useful way to spend your resources - the other ways are bound to be easier if the XML is more than a simple, single table which seldom changes.
>
>my 2 cent (EUR, that is)
>
>thomas