Possible Duplicate:
Programmatically Create XML File From XSD
XML instance generation from XML schema (xsd)
How to generate sample XML documents from their DTD or XSD?
Here's the scenario: I've created an application that hooks into a commercial CRM product using their web service API, which unfortunately has a different schema for every installation, based on how the users create their custom fields. This schema can also be modified at any time. This application will be installed at the customer location, and will need to function even when they change their field structure.
In order to insert or update a record, I first call their Project.GetSchema() method, which returns the XSD file based on the current set of fields, and then I can call the Project.AddProject() method, passing in an XML file containing the project data.
My question is: What's the best way to generate the XML from the XSD file at runtime? I need to be able to check for the existence of fields, and fill them out only if they exist (for instance, if the customer deleted or renamed some fields).
I really don't want to have the application attempting to recompile classes on the fly using xsd.exe. There simply must be a better way.
[update] My current solution, that I'm working on, is to basically parse out the XSD file myself, since the majority of the schema is going to be the same for each installation. It's just an ugly solution, and I was hoping there was a better way. The biggest problem I have is that their schema uses xsd:sequence, so putting things in a different order always breaks validation.
Related
Currently we have a XML Schema and the code reads the xml file, validates against the schema and save to database. In future there would be schema changes, how can the code handles them without needing to rewrite the code for new schema.
Thanks,
Let me give an example
<Products>
<product id="1">
<name> ABC </name>
<desc> good one </desc>
</product>
</products>
XPath mapping configuration
Table Column XPath
Product id //Products/product/id
Product name //Products/product/name
Product desc //Products/product/desc
Now the C# code reads id, name and desc and generates an insert statement based on the Mapping configuraiton
If the schema changes and new element is added say price and we would add that price to mapping, so the new insert statement that is generated includes price.
Will this work?
I hate parsing XML and loading it into objects. Due to this, you can try the following approach.
Create a C# object that represents the XML data you are talking about. Serialize that C# class, and viola you have an XML schema that is strongly typed. Also, if in the future you need additional schema changes, simply modify the C# class and reserialize and you're all set.
This also removes the need to parse the XML document (assuming you are utilizing it within the CLR), as you can simply reference the C# class and you can deserialize it back into memory without any parsing.
The way of handling something like this that immediately comes to mind would be to have a known good skeletal XML schema with no data in it, have the code parse and learn that schema, and then have it run on whatever arbitrary input you give it. When the XML schema changes, simply have a trusted user/admin go in and change the known good skeleton.
You should make sure your database can handle these changes without any extra prodding, and you should most definitely have at least a few tests that run regularly and throw off alerts if a problem is detected. One of the most dangerous elements in 'low maintenance' processes like these is that they often fail quietly and there's no way to tell they're broken!
I'm a little afraid I'm not getting your whole question because you added a bunch of tags that aren't obviously in your question, but hopefully this helps.
If the location for the XML data changes, unless you want to abstract the crap out of your XML file (include metadata in the document describing where to find things) you're out of luck. If your data elements will always be in the same place, all you have to do is keep your XSD file as a separate file, and change it when necessary to validate the document.
In my situation, I have a C# DLL I wrote myself that has been registered in a SQL Server database containing sales/customer data. As of now, I'm a bit stuck.
The DLL makes a call to a remote server to obtain a token. The token is then added to the database. Ideally, the next step is to retrieve data from the SQL server into the DLL and then build and post a JSON file to a remote server, using the token the DLL retreived.
Where I am stuck is there are 134 elements, with different data types, in the receipt section of my JSON file alone. I will need to be able to handle all of that data in my C# DLL and in the future I may need to pull a lot more data into this JSON file to be posted. I've done some reasearch and using user defined type (UDT) wouldn't quite work and from what I can tell, is an option I should stay away from. My other two options I know of would be to either export to XML and parse it in my DLL or to create and read in 134+ variables.
My question is: Is there a simpler way to do this besides XML/hard coding? It would be ideal if there was a way to use an array or an object but neither seem to be supported according to what I've read here
Thank you.
Important note: Because of the database and the JSON library I'm using, I'm working in .Net framework 2.0
I would recommend you to use XML serialization on the C# side. You create an object that models your database schema.
As you are using .NET 2.0 you have already a good set of base classes to model your database schema in an object oriented way. Even nullable columns can be mapped to nullable objects to save memory and network space.
From your SQL side you use the FOR XML clause, that will change the output of your query from tabular to XML. You have to make just one good SP that will create XML in the exact hierarchy as your C# objects.
This XML has to match the names and the casing of the classes and the properties of your c# class(es).
Then you will de-serialize this XML from the C# side in no more than 10 lines of code. No matter how big or how complex the data hierarchy is, and you will have instantly in memory objects that you can immediately serialize into JSON again.
Let me know if you need some good examples on how to achieve this. And please clarify if you are running inside of the SQL Server CLR execution context, as you might need special permissions for serializing/deserialize data.
I guess its a very primitive way of achieving what Entity Framework does. but it works.
You should probably stick with using XML as your data is semi-structured. Especially if you know your schema will be changing overtime. SQL Server is not yet an OODBMS.
I have a .NET webforms application that consumes data from a WCF/REST web service. Most of the time, we use shared classes to pass data back and forth, and that works well.
However, occasionally we need to display this data in a Datagrid or similar .NET control, and the most convenient way to do this is via a Dataset. I know we can read XML into a dataset using the Dataset.ReadXML(myXML, XmlReadMode.InferTypedSchema) method, and that's been working OK.
Occasionally, though, the InferTypedSchema infers the wrong datatype. For example, it'll decide that a zip code is an integer, not a string.
What are my options? I know I can manually define the dataset schema, but I'd like to avoid that if possible. The web service automatically generates an .xsd (ie, the autogenerated response/schema URL) - is there any way to tell Dataset.ReadXML to use that? Or is there a better way?
I know you can feed your DataSet not just with data but also with schema, something like
dataSet.ReadXmlSchema(new System.IO.StreamReader("schema.xsd"));
so if you have the xsd should be fine.
If you know your XSD ahead of time, you can generate a class file from that and then tweak it to ensure you have the right data types (strings for zip code).
XML Schema Definition Tool (Xsd.exe)
Once your create your class file, you can use XmlSerializer.Deserialize to convert your XML to a class.
I've been tasked with the job of importing a set of XML files, transform them and upload them to an SQL database, and then re-transforming them to a different XML-format.
The XML files are rather large, and some of them a little complex, so I'm unsure of the best way to do this. I'd of course like to automate this process somehow - and was actually hoping there'd be some kind of Entity Framework-esque solution to this.
I'm quite new to handling and dealing with XML in .NET, so I don't really know what my options are. I've read about XSLT, but that seems to me, to be a "language" I need to learn first, making it kind of not a solution for me.
Just to set a bit of context, the final solution actually needs to import new/updated versions of the XML on a weekly basis, uploading the new data to sql, and re-exporting as the other XML-format.
If anyone could give me any ideas as to how to proceed, I'd be much obliged.
My first instict was to use something like XSD2DB or XML SPY to first create the database structure, but I don't really see how I'm then supposed to proceed either.
I'm quite blank in fact :)
XSLT is language used by XML processors to transform XML document in one format to XML document in another format. XSLT would be your choice if you don't need to store data in database as well.
All tools like XSD2DB or XML SPY will create some database schema for you but the quality of the schema will be very dependent on quality of XML document and XSD (do you have XSD or are you going to generate it from sample XML?). The generated database will probably not be to much useful for EF.
If you have XSD you can use xsd.exe tool shipped with Visual studio and generate classes representing data of your XML files in .NET code. You will be able to use XmlSerializer to deserialize the XML document into your generated classes. The problem is that some XSD constructs like choice are modeled in .NET code by very ugly way. Another problem can be performance if your XML files are really huge because deserialization must read all data at once. The last problem can be again EF - classes generated by XSD will most probably not be usable as entities and you will not be able to map them.
So either use EF and in such case you will have to analyze XSD and create custom entities and mapping to your own designed database and you will fill your classes either from XmlReader (best performance), XmlDocument or XDocument or use some tool helping you creating classes or database from XML and in such case use direct SQL to work with a database.
Reverse operation will again require custom approach. You will have data represented either by your custom EF entities or by some autogenerated classes and you will have to transform them to a new format. You can again use xsd.exe to get classes for a new format and write a custom .NET code filling new classes from old ones (and use XmlSerializer to persist a new structure to XML) or you can use XmlWriter, XDocument or XmlDocument to build target XML document directly.
Data migration in any form is not easy task with ready to use solution. In case of really huge data processing you can use tools like SQL Server Integration Services where you will interact with XML and SQL directly and process data in batches.
Have a look at SQLXML 4.0. It does exactly what you want (in upload part).
I have a requirement to copy the tables from one DB to another . The table names (to be used in the application) are configured in the XML file.
This works out if the tables doesn't have any relations. In case any of the tables have relations. What is the best way to proceed?
How to decide the XML schema? (how to specify master tables, if they are in turn dependent on other tables)
How to effectively parse the XML schema in C#, so that the master tables are loaded first.
Thanks,
Vijay
2.How to effectively parse the XML schema in C#, so that the master tables are loaded first.
NOT AT ALL. This is a toy data set (i.e. small), just use the Xml Serializer. No need to write parser.
1.How to decide the XML schema? (how to specify master tables, if they are in turn dependent on
other tables)
Experience, requrements and KISS principle. Sorry, this is so basic I dont know what else to write.
Using linq-to-sql, it is possible to have an external mapping in xml format between the classes and their properties and the table and column names they map to. Linq-to-sql have features for foreign key references etc. built in.
Using an external mapping source, you will have to do some work by hand. The basic steps are:
Create the database if not already created.
Write classes with the names that you want to use in the code. You could possibly use the SqlMetal tool to generate raw files that you can strip from mapping attributes.
Write an xml mapping file.
If you are not familiar with linq-to-sql I would recommend you to start with a toy project using the Visual Studio Designer, to quickly get started to get familiar with the technology.