read & update using reader

[ShilpaKumari]

Good sot, You need to elobrate it how they achieve

[Mycroft Holmes]

jrahma wrote:

using sql_reader1

I have never understood the reason so many devs use the reader, sure it is he most economic way to process data but the limitations are irritating. I ALWAYS get the data, all the data into a datatable/List<>, this frees up the connection, then I process the datatable. If the data set is too large then I get the data to process in chunks.

Never underestimate the power of human stupidity RAH

[Pete OHanlon]

If you are trying to update a value and you are already using the connection for reading data, you need to look at using a MARS connection (that's Multiple Active Result Set). Add MultipleActiveResultSets=true; to your connection string.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Onyx

[PIEBALDconsult]

With MySQL?

[PIEBALDconsult]

I have never understood the reason so many devs use the DataAdapter and load a whole butt-load of data at once when they don't use it all at once. Certainly, when I want to load a ListBox or something, I use a DataTable (loaded straight from a DataReader), but mostly I use only one record at a time -- to export or copy somewhere or update something. For what I do, I doubt the connection stays open significantly longer, but it sure saves on RAM and class instantiations. Bear in mind that I generally write Windows Services that cycle every ten to fifteen seconds, and not generally GUI apps that spend a lot of time just sitting there displaying a bunch of out-dated data. And when I do write a WinForms app that displays a butt-load of data, I often use a Service to create an (XML) export that the clients read, rather than have all the clients constantly clambering for database connections.

[Mycroft Holmes]

PIEBALDconsult wrote:

I generally write Windows Services that cycle every ten to fifteen seconds

Well I do write user apps that have the (outdated) data sitting in front of the user, with move to WCF we use observablecollections serviced to the UI. I suppose we could use the reader instead of the adapter, it is just a habit from the winforms when we used to datatable as the bindingsource to the grids.

Never underestimate the power of human stupidity RAH

[PIEBALDconsult]

Mycroft Holmes wrote:

grids

X| Wash your mouth out with tequila; you're better than that.

[Mycroft Holmes]

In this context a grid is a generic term for a collection control and with winforms I was always happy to bind a datatable to a datagirdview, the datatable is disconnected afterall. The cost of the datatable has always been irrelevant to the functionality that it brings. Then we were told to use services and I decided the UI should be silverlight so everything changed, now it's Oracle databases, WCF, observablecollections, viewmodels and xaml. Did I say I hate (relearning) Oracle.

Never underestimate the power of human stupidity RAH

[PIEBALDconsult]

Mycroft Holmes wrote:

(relearning) Oracle.

But not in C with Pro*C I bet.

[MDNadeemAkhter]

:-D

[Brady Kelly]

It is maybe neater to not use a reader, but rather a DataTable and a TableAdapter. Then you can loop through the table rows, update the is_sent on each row as you process it, and then call Update. Something like this:

using (var ad = new SqlDataAdapter("sp\_send\_pending\_sms", ConfigurationManager.ConnectionStrings\["SQLdb"\].ConnectionString))
{
    ad.SelectCommand.CommandType = CommandType.StoredProcedure;
    var dt = new DataTable();
    ad.Fill(dt);

    // blah blah blah. do your work.
    ad.AcceptChangesDuringUpdate = true;
    ad.Update(dt);
}

If the list is long, you may want to call Update every n rows, not just at the end.

[Gary Huck]

Yes, something like that is what you need. The ExecuteReader() method, as the name implies, is only for selecting (reading) data. p.s. Stored procedures are a great way to go!

[Gary Huck]

Tell us why one should NOT use stored procedures, as you state.

[Fabio Franco]

PIEBALDconsult wrote:

I have never understood the reason so many devs use the DataAdapter and load a whole butt-load of data at once when they don't use it all at once.

When you know there will never be too much data and that it will not have impact on system resources and when you want to work with data in a disconected state. There are good uses for both approaches, that's why they exist. Beeing wise to use them where they fit is another story, can't speak for anyone.

[Spectre_001]

You can not update through a DataReader. It retreives a read-only, forward-only stream of data one record at a time. If I read your question correctly, you are doing some processing on each record after reading, then need to set a flag in the database to indicate that record has been processed. You will need a second connection and comand object for this. You can't use the same connection/command as the DataReader because it keeps it's connection open internally throughout it's lifetime. The best way to accomplish this will vary slightly depending on how many records you expect to process and whether the processing will run a long time (cumulative). For a relatively short run: 1. Open SQLConnection for updating and attach to SQLCommand 2. Read next record from DataReader 3. Perform needed processing 4. Generate update SQL for current record 5. Use SQLCommand to run update SQL 6. Repeat steps 2 - 5 until last record has been processed and updated 7. Close and destroy update SQLConnection/SQLCommand For a long run: 1. Create SQLConnection for updating and attach to SQLCommand 2. Read next record from DataReader 3. Perform needed processing 4. Generate update SQL for current record 5. Open SQLConnection for update 6. Use SQLCommand to run update SQL 7. Close SQLConnection 8. Repeat 2 - 7 until last record has been processed and updated 9. Close and destroy update SQLConnection/SQLCommand Hope this answers your question and helps out.

Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower

[Miroslav Bucko]

That article is from 2003. And yeah, i'm wondering too, why?

[Jason Christian]

Short answer - You can't. It is a data READER - not an updater. It's not like opening a recordset in VB6. You need to ExecuteSQL with appropriate SQL to udpate the records (i.e. UPDATE table SET field=value WHERE key=id). To do it the way you want it would better to use a DataSet or something a little more robust - plenty of info on MSDN.

[Mycroft Holmes]

Nothing fundamental has changed in databases since 2003 so the premise of the article is still very valid, I just don't agree with it.

Never underestimate the power of human stupidity RAH

[PIEBALDconsult]

GamleKoder wrote:

is only for selecting (reading) data.

No it isn't; it can execute any SQL statement (even a list of them if the particular database engine supports it) and it underlies all the other ADO.net data manipulation methody, so you're using it whether you know it or not.

[PIEBALDconsult]

Spectre_001 wrote:

You can not update through a DataReader

No, but you can through ExecuteReader. In your scenarios... generate a parameterized update command up front and then set the parameters for each row and execute -- no need to keep generating the same SQL statement.