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.
Related
Objective
Build a PDF file which represents single C# class object with multiple fields and properties, that is created in runtime. It constains plain text, variables, tables, images.
What I have to use?
As a requirement, I have to render PDF report with Microsoft.Reporting.WebForms.LocalReport and it will probably contain SubReports.
What I did?
When working with reports until now, following simple pattern was enough:
ReportParameter param = new ReportParameter();
param.Name = "Param name";
but in that case I'd have to make over 80 parameters and I think it's just not a nice way, so I'm curious if there is better way to do that. Based on my researchers on SO and google, I can use System.Data.DataSet to achieve what I want, but:
It is only sightly better that hardcoding all the parameters
It is almost the same, but I produce additional files, IMO it's easier to use and understand ReportParameter way for future code users than getting burried in tons of extra files, that(maybe) could have been avoided
DataSets are for tabular data; I have one big model
Problem
Actually, I think the problem lies in DataSource of the RDLC report itself. The ways that VS provides are created for DB connection or any DB related object. That's why using DataSources and DataSets is indicated. I can provide any data that is either of type IEnumerable or IReportData (or from db connection), but mine are neither. I got my model already build and I'd want to use it if possible.
Most examples I found was for creating reports straight from database or custom data sets. Got no more ideas how to make it work. That's why I'm here.
When using an external component is an option for you: I've been using the .NET reporting component "combit List & Label". It has PDF export and an object dataprovider included that takes any .NET object or even object structure and provides the object`s properties as variables/parameters in an interactive report designer for tables, charts, etc.
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'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).
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.
I am currently writing an IRC client and I've been trying to figure out a good way to store the server settings. Basically a big list of networks and their servers as most IRC clients have.
I had decided on using SQLite but then I wanted to make the list freely available online in XML format (and perhaps definitive), for other IRC apps to use. So now I may just store the settings locally in the same format.
I have very little experience with either ADO.NET or XML so I'm not sure how they would compare in a situation like this.
Is one easier to work with programmatically? Is one faster? Does it matter?
It's a vaguer question than you realize. "Settings" can encompass an awful lot of things.
There's a good .NET infrastructure for handling application settings in configuration files. These, generally, are exposed to your program as properties of a global Settings object; the classes in the System.Configuration namespace take care of reading and persisting them, and there are tools built into Visual Studio to auto-generate the code for dealing with them. One of the data types that this infrastructure supports is StringCollection, so you could use that to store a list of servers.
But for a large list of servers, this wouldn't be my first choice, for a couple of reasons. I'd expect that the elements in your list are actually tuples (e.g. host name, port, description), not simple strings, in which case you'll end up having to format and parse the data to get it into a StringCollection, and that is generally a sign that you should be doing something else. Also, application settings are read-only (under Vista, at least), and while you can give a setting user scope to make it persistable, that leads you down a path that you probably want to understand before committing to.
So, another thing I'd consider: Is your list of servers simply a list, or do you have an internal object model representing it? In the latter case, I might consider using XML serialization to store and retrieve the objects. (The only thing I'd keep in the application configuration file would be the path to the serialized object file.) I'd do this because serializing and deserializing simple objects into XML is really easy; you don't have to be concerned with designing and testing a proper serialization format because the tools do it for you.
The primary reason I look at using a database is if my program performs a bunch of operations whose results need to be atomic and durable, or if for some reason I don't want all of my data in memory at once. If every time X happens, I want a permanent record of it, that's leading me in the direction of using a database. You don't want to use XML serialization for something like that, generally, because you can't realistically serialize just one object if you're saving all of your objects to a single physical file. (Though it's certainly not crazy to simply serialize your whole object model to save one change. In fact, that's exactly what my company's product does, and it points to another circumstance in which I wouldn't use a database: if the data's schema is changing frequently.)
I would personally use XML for settings - .NET is already built to do this and as such has many built-in facilities for storing your settings in XML configuration files.
If you want to use a custom schema (be it XML or DB) for storing settings then I would say that either XML or SQLite will work just as well since you ought to be using a decent API around the data store.
Every tool has its own right
There is plenty of hype arround XML, I know. But you should see, that XML is basically an exchange format -- not a storage format (unless you use a native XML-Database that gives you more options -- but also might add some headaches).
When your configuration is rather small (say less than 10.000 records), you might use XML and be fine. You will load the whole thing into your memory and access the entries there. Done.
But when your configuration is so big, that you dont want to load it completely, than you rethink your decission and stay with SQLite which gives you the option to dynamically load those parts of the configuration you need.
You could also provide a little tool to create a XML file from the DB-content -- creation of XML from a DB is a rather simple task.
Looks like you have two separate applications here: a web server and a desktop client (because that is traditionally where these things run), each with its own storage needs.
On the server side: go with a relational data store, not Xml. Basically at some point you need to keep user data separate from other user data on the server. XML is not a good store for that.
On the client: it doesn't really matter. Xml will probably be easier for you to manipulate. And don't think that because you are using one technology in one setting, you have to use it in the other.