Win a copy of Beginning ASP.NET 1.1. Databases
In some of the entries to our last competition a number of people asked us about various aspects of ASP.NET. There were even those <gasp> who suggested they used Visual Studio alongside Dreamweaver.
In immediate response, and in conjunction with Apress, we're giving you the chance to read a sample chapter from the forthcoming Beginning ASP.NET 1.1 Databases book by experienced .NET authors Dan Maharry and Damien Foggon.
Of course we've twisted the publisher's arms on your behalf, and have five books to give away to registered DMXzone members. All we want from you is to know either which bits of ASP.NET you've found most useful, or which you've found hardest to get to grips with. Lucky entries will be extracted by a draw from the inbox on the 22nd July!
The DataReader Object
The key to the whole topic of data handling is the DataReader object—or, if you prefer to be data provider–specific, the SqlDataReader, OleDbDataReader, and OdbcDataReader objects. True, they're optimized as appropriate for the technology they're based on, but their method calls and properties are, for all intensive purposes, identical, so we can just as easily refer to them all in one go. Rest assured that if we come to any incongruities, we'll make a note of them before continuing.
The DataReader is a strange little object. You may use it all the time, but it's intangible, representing only a pipeline in memory between the database and the Web page waiting for the data. In functional terms, it works much like a phone connection. While the phone connection is open, the page can speak queries to the database, which in turn can speak its results back to the page, but once the connection is closed, there's no trace of it or record of the data returned from the database except in the page itself.
Only if you use another object, such as the DataSet, can you maintain an in-memory record of the results from the query. If you like, the additional object is the equivalent of an answering machine or phone-tapping mechanism.
The upshot of it only being a conduit in memory rather than a permanent place of storage is that when you access the data in a DataReader, the data is readonly. It also means you can access the results only one row at a time, and once you finish with a row and move onto the next one, you can't go back to it. You can go only forward.
Ian Blackham
Following a degree in Chemistry and a doctorate in Scanning Tunneling Microscopy, Ian spent several years wrestling with acronyms in industrial R&D (SEM with a side order of EDS, AFM and TEM augmented with a topping of XPS and SIMS and yet more SEM and TEM).
Feeling that he needed a career with more terminology but less high voltages, Ian became a technical/commissioning editor with Wrox Press working on books as diverse as Beg VB Application Development and Professional Java Security. After Wrox's dissolution and a few short term assignments Ian became content manager at DMXzone.
Ian is a refugee from the industrial Black Country having slipped across the border to live in Birmingham. In his spare time he helps out with the website of a local history society, tries to makes sure he does what his wife Kate says, and worries that the little 'un Noah is already more grown up than he is.