How do you load a DataSet at runtime?
Sunday, August 22, 2010 7:17 PM
Ever want to stick a DataSet into your program, just not sure how? Read on for two ways to do it.
I'm working on a program where one piece of functionality I want is, to load up a static DataTable. hhhhhmm the little mouse in my head is thinking if that table doesn't change very much, I can actually stick it into the DLL itself and pull it out at runtime. Cool! But how do you THAT? Turns out there are two ways to do that, read on for how.
The first way I thought about this was with sticking the XML in the DLL, but I'll finish with that one.
The way I want to start illustrating is just taking the generated XML file (created with the first project) and sticking it into the resources directly. You'll notice the "DataSet" is no longer a DataSet, it's just another file which contains a String. This is no big deal, just that when you go to pull out the DataSet you have to be aware, it's a String and not a DataSet.
Here's how you read the String into a DataSet you can use. The whole magic here is how to tell VS to FIND the file you want, and is also the HUGE bonus for using this method. Why? Cause the name of your resource is strongly typed! BONUS! Ya, Intellisense can help you find it! Beaut!
private void LoadDataByResources_Click( object sender, EventArgs e )
StringReader reader =
ds.ReadXml( reader );
BindData( ds );
The key thing to notice here is the code in the StringReader constructor. Notice how it's explicitely the entire assembly name, starting with the top level project namespace, then includes the Properties.Resources namespaces, then followed by the name given (either by VS or you) in the Project Resources dialog listed above. Cool!
PS The ds.Clear() and BindData() are just extra code to make the winform work for the demo if you try to download it. The key here are the two lines which create the StringReader (remember, the XML in the Resource is a String datatype and not an XML file) and the ReadXML call.
Next, as promised, is grabbing the DataSet out of the assembly, but this time, it's "cooked" right into the .exe or .DLL. That means you have to setup your file in your project and tell VS it's an "Embedded Resource" for the Build Action.
Next, you need code to pull out the string.
private void LoadDataByXML_Click( object sender, EventArgs e )
Assembly assembly = Assembly.GetExecutingAssembly();
Stream stream =
StreamReader reader = new StreamReader( stream );
ds.ReadXml( reader );
BindData( ds );
The key here, like above, is the naming of the resource and telling the CLR how and where to find it. The "where" is the GetExecutingAssembly() call, and the "how" is the big long string in quotes. Ya, this is the major hiccup with doing it this way, it's not strongly typed, and if you get it wrong, you'll get a null coming out for your stream. DOH! Not so good.
I decided to go with the latter method because once I got the naming down pat and the CLR could find the XML in the EXE, I can easily change/update/modify that XML in the project without fear of second guessing VS if it's going to actually get updated in the resources using the first way. At the end of the day, I'd be interested in know if down under the covers, if VS and the CLR are doing the exact same thing for both methods. If so, then the strongly named method would win hands down.
Now that you know how to read a DataTable out of a Resource, it's time to grab a coffee and get coding.
PS If you're asking me, what's up with this simple code demo? haha I'm working on a subsequent blog this week to show how to do a left outer joing in the two DataTables but without using LINQ nor having current/live access to the source database. Yup, that's the next blog.
Source Code: http://www.pchenry.com:8080/svn/blog/trunk/2010/ReadingFromResources