MySQL data connection
-
I have a treeview that I populate with data from various tables in mysql db. I also update the tables based on user actions. I was wondering, is it more efficient to use a mysqlDataAdapter for this or just CommandText and MySql Reader for populating and then separate CommandText statements for updating?
-
I have a treeview that I populate with data from various tables in mysql db. I also update the tables based on user actions. I was wondering, is it more efficient to use a mysqlDataAdapter for this or just CommandText and MySql Reader for populating and then separate CommandText statements for updating?
A reader done right is usually, almost always, faster than a data adapter, dataset solution. In the cases where timings show a data adapter executing faster there is usually a flaw in logic. Where the Data Adapter and data set solutions are usually faster is in Dev/Time not run time.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
A reader done right is usually, almost always, faster than a data adapter, dataset solution. In the cases where timings show a data adapter executing faster there is usually a flaw in logic. Where the Data Adapter and data set solutions are usually faster is in Dev/Time not run time.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
10!
-
I have a treeview that I populate with data from various tables in mysql db. I also update the tables based on user actions. I was wondering, is it more efficient to use a mysqlDataAdapter for this or just CommandText and MySql Reader for populating and then separate CommandText statements for updating?
Avoid DataAdapters for real work; their only purpose is to allow MS demonstrators at launch events to produce a barely-working program in the time allowed.
-
A reader done right is usually, almost always, faster than a data adapter, dataset solution. In the cases where timings show a data adapter executing faster there is usually a flaw in logic. Where the Data Adapter and data set solutions are usually faster is in Dev/Time not run time.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
While I wasn't looking for an answer to that question, it will certainly come in handy for a project I'm working on - one of several. Thanks! Is not a reader a one-way solution, though; that is, for reading from a database in one direction? And a data adapter is more of a random access solution? Such additional overhead would certainly explain the performance difference.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
While I wasn't looking for an answer to that question, it will certainly come in handy for a project I'm working on - one of several. Thanks! Is not a reader a one-way solution, though; that is, for reading from a database in one direction? And a data adapter is more of a random access solution? Such additional overhead would certainly explain the performance difference.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
A common misconception. ADO.NET is exclusively a fast-forward, read-only cursor. The data adapter uses a data reader behind the scenes to get the data. What the data adapter does is attempt to infer the schema from the available result sets and then read to the end of all cursors populating a data set. You then get your data in a handy data set with associated overhead. AFAIK there is not an ADO.NET solution intended to maintain an open cursor to the DB at all.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
While I wasn't looking for an answer to that question, it will certainly come in handy for a project I'm working on - one of several. Thanks! Is not a reader a one-way solution, though; that is, for reading from a database in one direction? And a data adapter is more of a random access solution? Such additional overhead would certainly explain the performance difference.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
DataReaders underly all ADO.net access; including ExecuteScalar, ExecuteNonQuery, and DataAdapter.Fill and .Update Learning to use them effectively will make you a better developer. And chicks dig it. :cool:
-
A common misconception. ADO.NET is exclusively a fast-forward, read-only cursor. The data adapter uses a data reader behind the scenes to get the data. What the data adapter does is attempt to infer the schema from the available result sets and then read to the end of all cursors populating a data set. You then get your data in a handy data set with associated overhead. AFAIK there is not an ADO.NET solution intended to maintain an open cursor to the DB at all.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
with associated unnecessary overhead :-D
-
DataReaders underly all ADO.net access; including ExecuteScalar, ExecuteNonQuery, and DataAdapter.Fill and .Update Learning to use them effectively will make you a better developer. And chicks dig it. :cool:
PIEBALDconsult wrote:
And chicks dig it
Well, that's good enough for me! :-D
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
A common misconception. ADO.NET is exclusively a fast-forward, read-only cursor. The data adapter uses a data reader behind the scenes to get the data. What the data adapter does is attempt to infer the schema from the available result sets and then read to the end of all cursors populating a data set. You then get your data in a handy data set with associated overhead. AFAIK there is not an ADO.NET solution intended to maintain an open cursor to the DB at all.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
Back to the books... :sigh:
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Avoid DataAdapters for real work; their only purpose is to allow MS demonstrators at launch events to produce a barely-working program in the time allowed.
thanks for all the info. I've been using DataReaders so far and just came across the adapter. So I'll stick with the reader.