How do you get at the data within a DataSet once you've Fill()ed it Not from a form, but from with the application.
This frustration is also heading towards disappoinment. The examples never seem to do anything. They get you to a point and then leave you dangling.
This is an ideal way to ensure the after market for books etc. thrives...
The "Build a Program Now!" e-book was fantastic, but it moved to quickly from "Hello World" to fully fledged windows app.
It's not as if I don't know what I'm doing, but things have changed dramatically from the original ADO stuff to ADO.Net and there is nothing that comes close to a decent tutorial on this stuff.
If anyone does know of a good ADO.Net tutorial then please let me know, 'cos the supplied documentation assumes a working knowledge of how this thing fits together.
(I'll get off my soapbox now
)Cheers,
Roy
Why do all examples assume you're binding data to a control?
Gagan Sharma
Thanks for the response. I'm finding my way around slowly and what your saying is starting to make sense. I'm not trying to bypass the latest binding capabilities, but trying to do some good "old fashioned" data manipulation which has no need for a UI. Which is why my frustration kicks in everytime I see another windows app example...
My.SoapBox = True
One thing that has struck me though. When I used to teach OOP back in the late 80;s early 90's much was to be said about polymorphism and in general the latest stuff follows this well.
Then we get to ADO.Net. Now maybe I'm just being picky but why should I have to go to all the trouble of the syntac you quote: MyDataSet[TableName].Rows[MyDataRow][MyIndexer] when for a DataReader you can simply do MyDataReader.Read(), MyDataReader(MyColumnName).
To be consistent, this should be applied across the whole spectrum of data access containers. If for example you maintained a relationship within a DataSet, .Read() would move the parent table to the next row, and align all child tables accordingly.
If your DataSet was just a collection of tables, then you should be able to perform a MyDatSet(TableName).Read() with a MyDataSet(TableName)[MyColumnName]
Or even better:
MyDataSet.Table.Read() with a MyDataSet.Table(MyColumName)
Or what about:
MyDataSet.CurrentTable = "TableName"
MyDataSet.Read()
MyDataSet(MyColumnName)
Now, I'm not sure how easy the last two would be to implement, I haven't got that deep in to the class capabilities yet, but to add .Read() capabilities to a DataTable would not be difficult and would enable some interoperability between DataReaders and DataTables.
This is what derailed me - I just assumed that because you could .Read() a DataSet you could .Read() a DataTable, and when I couldn't finding an example was not easy (although I did find one in the end), and even then the syntax of use made me even more irate as I had to go to the depths of syntax you give above to simply read forward through a cach of my data.
My.SoapBox = False
Cheers,
Roy
Hattrick
But a dataset is not the same as the old ADODB recordset.
A dataset for all intents and purposes is a full-fledged relational database
and it contains two collections
tables and relations
Previously this was only (somewhat) available via the unweildly MSDataShape Provider.
I think when you play around with typed datasets you will see the usage you are looking for and then the beauty of the ADO.NET Dataset will shine through.
Stick with it! It will begin to make sense!
Rogério R. Alcantara
you can think of a Dataset as container for a DataTableCollection (Tables)
Each DataTable in the collection can be thought of as a Container for a DataRowCollection (Rows)
You can think of a DataRow as simply an object with various indexers that get the value out of the row based on a column ordinal, a column name or a datacolumn, or any of the previous and a row version.
MyDataset.Tables[MyTableName].Rows[MyDataRow][MyIndexer] = SomeValue
object SomeValue = MyDataset.Tables[MyTableName].Rows[MyDataRow][MyIndexer];
I like O'Reilly's 'ADO.Net in a nutshell' granted it covers ADO.NET 1.1.
(stepping on to my soapbox
and yes, the ADO.NET paradigm can be a bit confusing coming from ADODB. . . and especially if you were used to VBSUX.
Forget everything you learned in VBSUX! 99% of it was wrong!
VBSUX made databinding difficult. Which is why so many people errantly suggest not to use it. Simply put, they didn't understand it! It's not their fault. VBSUX had terrible support for databinding that was matched only by even shoddier documentation! Fortunately, Microsoft hired Anders Hejlsberg (the man behind Borland Delphi) to come in and fix everything! Man, Microsoft Development Tools prior to .Net were absolutely attrocious!
Now I certainly hope you are not trying to circumvent databinding and load the data directly into controls so you can manage the presentation and editing of your data, i.e. manually iterating though a datatable and loading the data into a listbox. That would be ridiculous!!!!
Now with .Net 2.0 we get the bindingsource and bindingnavigator we FINALLY get decent databinding support in a microsoft environment that we former Delphi developers are so used to!
(Now I'll get off my soapbox
scasti1
I do get this and I agree - seperate UI from app logic from data access. Has been my core principle since my Clipper days - but not always easy to implement ;-)
Even so, why should there be more than one way to "progamatically" read and access your data. The DataReader is so simple - as it should be, but everything else seems to require that much more work - when there is no need for there to be...
Cheers,
Roy
Roman Pereyaslavsky
Perhaps the DataReader is simple but I think the DataAdapter is even more so. It's quite easy to fill your DataSet with DataAdapter.Fill(MyDataSet). How can it get any easier
And I'm 100% behind using Typed DataSets ... it's the *only* way to fly, IMHO. ;-)
Claude Eisenhut
Great! Looking forward to it! So where do I find out about it
Documentation is always so fragmented and trying to adopt the principles of ADO.Net from scratch is somewhat bewildering.
I'm literally putting to one side (or trying to) everything I've used before so I can approach all this a new. However as this is now a hobby and no longer my bread and butter, its gonna take longer than it used to and on a much, much lower budget.
Ideas and suggestions on a postcard please... ;-)
Roy
Haibo_Luo
what is your environment -
Visual Studio 2005 w SQL server
Express with SQL Express
Visual Studio 2003
It seems that the .Net 1.1 SDK had some better samples when it came to datasets.
I really recommend the O'Reilly ADO.NET Nutshell book.
This book looks good (though I don't own it) Pro ADO.NET 2.0. I really like the Apress titles.
Pepper
The big difference, to me, with using a DataReader versus using a DataSet (or DataTables), is that by using a DataReader, you have not separated your data access from your UI. With a DataSet, you have a disconnected means of managing your data ... your DataAccess should be in a separate class anyway, not in your UI.
~~Bonnie
Paul Diterwich
I'll start to look for books in the new year. I was kinda hoping that there would be more getting starting guides available...
Cheers,
Roy