Can someone explain me DataSet.Copy() vs Dataset.Clone()
Also let me know some scenario's where we can use these
Clone will create a new, empty DataSet with the same schema (tables and columns) as the old one. The new DataSet will not have any data.
Copy does the same thing, but also copies the rows in the tables.
Clone copies the only the structure of the dataset where as Copy copies the data as well.
http://www.dotnetspider.com/forum/ViewForum.aspx?ForumId=52327
The Clone() method creates a new DataSet with the same structure. The Copy() method does too, and copies the data.
DataSet.Copy copies both the structure (tables, relations etc) and the data.
DataSet.Clone copies only the structure of the DataSet.
.Clone returns a data set with exactly the same schema but without any rows, .Copy returns both the schema and the rows.
Related
basic question - is it possible to populate a combobox with datasource and then cut the link to the datasource, but keep the data in the combobox? this will enable you to reuse your ds.Tables[0] below without affecting the first populated combobox.
comboBox1.DataSource = ds.Tables[0];
(The ds is populated from MS SQL Server with SqlDataAdapter)
No, it is not possible without copying the source data in some way. The DataSource property is a reference to your dataset, datatable or whatever object not a copy of it. Setting DataSource to null will remove any possibilities for the combo to see the data referenced.
Instead you could easily create a copy of your original table using the appropriate method available in the DataTable class
comboBox1.DataSource = ds.Tables[0].Copy();
This create a new copy of the table with the actual structure and content, but it is a copy in another memory area of the informations stored in the first object. At this point you have two distinct objects in memory and you can change the first one without affecting the second.
Let me say also that this is not very smart with big tables. Don't use this approach if your table contains a lot of records for obvious reasons.
We have created a custom dataset and populating it with some data.
Before adding data, we are adding columns in the data set as follows
DataSet archiveDataset = new DataSet("Archive");
DataTable dsTable = archiveDataset.Tables.Add("Data");
dsTable.Columns.Add("Id", typeof(int));
dsTable.Columns.Add("Name", typeof(string));
dsTable.Columns.Add("LastOperationBy", typeof(int));
dsTable.Columns.Add("Time", typeof(DateTime))
Once the Dataset is create, we are filling values as follows
DataRow dataRow = dsTable.NewRow();
dataRow["Id"] = source.Id;
dataRow["Name"] = source.Name;
dataRow["LastOperationBy"] = source.LastOperationBy;
dataRow["Time"] = source.LaunchTime;
Is there any better and managed way of doing this. can I make the code more easy to write using enum or anything else to reduce the efforts?
You could try using a Typed Dataset.
This should get rid of the ["<column_name>"] ugliness.
If the dataset has a structure similar to tables in a database, then Visual Studio makes it really easy to create one: just click Add -> New Item somewhere in the solution and choose DataSet. VS will show a designer where you can drag tables from your server explorer.
Update (after response to Simon's comment):
A typed dataset is in fact an XSD (XML Schema Definition).
What I did in a similar case was:
created an empty DataSet (using Add -> New Item -> DataSet)
opened the newly created file with a text editor (by dafault, in VS it shows the XSD designer)
paste the XSD that I had created manually
You could also choose to use the designer to create the schema.
Considering your comment "I am using Dataset to export data to a XML file" I recommend using a different technology such as
Linq to XML http://msdn.microsoft.com/en-us/library/bb387061.aspx or
Xml Serialzation http://msdn.microsoft.com/en-us/library/system.xml.serialization.xmlserializer.aspx
Or better yet of is doesnt have to be XML (and you only want hierarchical readable text consider JSON instead http://james.newtonking.com/pages/json-net.aspx
You can bind dataset in two way first one is using database second one is add manually.
After create column for dataset you can add using Loops you can add it if you have 10000 of entries.
You can use Reflection. Another option is to use EntityFramework or NHibernate to map the columnnames and datastructure columns and then avoid these code to fill each field manually. But they will add more complexity. Also Performance wise the your code is better.
I'm consuming a 3rd-party web service that outputs a Dataset (from XML). I'd like to create a new table in my local MS Access database that contains the DataSet data.
Is there a simple way to hand-off the DataSet to a .net object and ask it to "create a table from this"?
I know that we can use different parts of ADO to extract schema, build commands, insert rows, etc. I figured there has to be a simpler way.
The only two ways I know of are to
Walk through the DataSet field by
field and generate a DDL instruction
(which is valid for MS-Access)
Add a reference to ADOX, create a new table (with columns) and append the new table to the ADOX catalog. More info here. But again you are walking throught the dataset table field by field.
I haven't provided much detail on either of these approaches since I don't think they match what you've specified.
It seems you are looking for a quicker way than either of those so I guess the answer to your question is no.
Suppose I have an ADO.NET DataTable that I was to 'persist' by saving it to a new table in a SQL Server database - is there a fast way of doing this?
I realise I could write code generating the DDL for the 'CREATE TABLE' statement by looping through the DataColumns collection and working out the right type mappings and so on ... but I'm wondering if there is an existing method to do this, or a framework someone has written?
(NB: I need to be able to handle arbitrary columns, nothing too fancy like blobs; just common column types like strings, numbers, guids and dates. The program won't know what the columns in the DataTable are until run-time so they can't be hard-coded.)
ADO.net cannot create tables in SQL Server directly, however, SMO can do this with the .Create method of the Table class. Unfortunately, there is no built-in way to use a DataTable to define an SMO Table object.
Fortunately, Nick Tompson wrote just such a DataTable-to-SMO.Table routine back in 2006. It is posted as one of the replies to this MSDN forums topic http://social.msdn.microsoft.com/forums/en-US/adodotnetdataproviders/thread/4929a0a8-0137-45f6-86e8-d11e220048c3/ (edit: I can make hyperlinks now).
Note also, the reply post that shows how to add SQLBulkCopy to it.
If the table exists, you can use SqlBulkCopy (which will accept a DataTable) to get the data into the table in the fastest possible way (much faster than via an adapter). I don't think it will create the table though. You might have to write the DDL yourself, or find some existing code to loop over the DataTable.Columns to do it.
I think this post can help
I might be easier to store your DataTable as XML. just create a table with an XML column.
What is the fastest way of transferring few thousand rows of data from one DataTable to another? Would be great to see some sample code snippets.
Edit: I need to explain a bit more. There is a filtering condition for copying the rows. So, a plain Copy() will not work.
You can't copy the whole table, you need to copy one rows. From http://support.microsoft.com/kb/308909 (sample code if you follow the link)
"How to Copy DataRows Between DataTables
Before you use the ImportRow method, you must ensure that the target table has the identical structure as the source table. This sample uses the Clone method of DataTable class to copy the structure of the DataTable, including all DataTable schemas, relations, and constraints.
This sample uses the Products table that is included with the Microsoft SQL Server Northwind database. The first five rows are copied from the Products table to another table that is created in memory."
What is wrong with DataTable.Copy?
Copying rows to a table throws some flags at me. I've seen people try this before, and in every single case what they really wanted was a System.Data.DataView. You really should check to see if the RowFilter property will do what you need it to do.