I recently received an assignment that required the production of output produced from an SQL Server query as an XML document. Obtaining the data was no problem as I have worked with SQL Server, Datasnap an client datasets in the past. What gave me lots of problems was the XML output. Using XE7.

I recently received an assignment that required the production of output produced from an SQL Server query as an XML document. Obtaining the data was no problem as I have worked with SQL Server, Datasnap an client datasets in the past. What gave me lots of problems was the XML output. Using XE7.

I used a DatasetProvider and XMLTransformClient to obtain the output. Also used the XML Mapping Tool as I was not given a schema, but rather "sample output." An auxiliary tool was also used, Aptana Studio 3 (open source, free).

The Mapping Tool creates a schema from an input XML file but in fact, the Schema will not validate; it contains errors. (It's also ugly, but that's a side issue.) Specifically, it generates invalid attributes at the Schema level and also generates duplicate global names.

My final Mapper workaround was:
1. Open XML (Schema generates)
2. Proceed with field definitions and mappings as needed
3. Generate data packet (this works as advertised and is used to create the ClientDatasets)
4. Generate the transform from XML to Datapacket (saved although not required for what I was doing)
4. Generate the transform from Datapacket to XML. Saved for use in final XML export)

After creating the final XML export the schema generated by the mapper is not usable because of the errors. I got around this by using another tool to generate a valid schema from the original XML. http://www.freeformatter.com/xsd-generator.html

I have not been able to find any mention of XML Mapper bugs in the customary places. My questions:

Has anyone run into this before?
Is it a bug or am I doing something wrong?

If it's a bug, how do we get it fixed?

TIA
http://www.freeformatter.com/xsd-generator.html

Comments

  1. Hey, thanks to everyone for responding to my question. However, nobody actually answered my question directly, instead offering suggestions on how to change the design of the solution. By implication, I take that to mean that nobody likes the Delphi solution and it probably is buggy. I didn't actually ask for these alternatives since I currently have a working solution that is all Delphi, but I'll file these comments away for future reference.

    Thanks again, to all!

    As a side comment, I am somewhat interested to see that the solutions suggested on a Delphi group pointedly advise against using Delphi. I guess that means Embarcadero has some work to do. (RU listening David I. and Marco?)

    How do I report these bugs. Is QC still alive?

    ReplyDelete
  2. Milan Vydareny it is complicated. Like any tool, Delphi has strengths and weaknesses. This part has some weaknesses that have not had attention for a long time. Since a toolbox should consist of many tools, others are better suited than Delphi for this problem. .Net is well suited here. It's the classic "pick the right tool for the problem". For building a business GUI I'd pick Delphi hands down. But not for XML stuff. Note that even in the .NET and Java worlds that traditionally support XML well, there are XML issues.

    ReplyDelete

Post a Comment