|
Introduction
ADO.NET is a model intended primarily for disconnected data access. ADO.NET
provides two strategies for you to work with this model.
Store data in a dataset, which is an
in-memory cache of records you can work with while disconnected from the data
source. To use a dataset, you use a data adapter to fill it from the data
source. You then work with the data in the dataset.
Perform operations directly against the
database. In this strategy, you use a data command object. You can then open a
connection, execute the command to perform the operation, and then close the
connection.
Each strategy has its own advantages. So you
should choose a strategy based on what your data-access requirements are.
Advantages of Storing Data in Datasets
The advantages of the dataset model are:
- Data exchange with other applications - A
dataset provides a powerful way to exchange with other components of your
application and with other applications.
- Moving data between tiers in a
distributed application - By keeping data in a dataset,
you can easily move it between the presentation tier, business tier, and
data tier of your applications.
- Working with multiple tables - A
dataset can contain multiple tables. You can work with the tables
individually or navigate between them as parent-child tables.
- Maintaining records for reuse - A
dataset allows you to work with the same records repeatedly without re-querying
the database.
- Manipulating data from multiple sources - The
tables in a dataset can represent data from many different sources. Once
the data is in the dataset, you can manipulate it and relate it as if it had
come from a single source.
- Data binding - If you
are working with forms, it is usually easier to bind controls to data in a
dataset than it is to programmatically load data values into the control
after executing a command.
- Ease of programming - When
you work with a dataset, you can generate a class file that represents its
structure as objects. This makes it easier, clearer, and less error-prone to
program with, and is supported by Visual Studio tools such as IntelliSense,
the Data Adapter Configuration wizard, and so on.
Advantage of performing Database Operations Directly
The advantages of performing database operations directly:
- More control over execution - By
using commands, you get more direct control over how and when an SQL
statement or stored procedure is executed and what becomes of the results or
return values.
- Less overhead - By reading and writing directly in the database,
you can bypass storing data in
a dataset. Because the dataset requires memory, you can reduce some overhead
in your application. This is especially true in situations where you intend
to use the data only once. In that case, creating and filling a dataset
might be an unnecessary step in displaying the data.
- Extra functionality - There
are some operations, such as executing DDL commands, that you can run only
by executing data commands.
- Less programming in some instances - In
a few instances, particularly Web applications, there is some extra
programming required to save the state of a dataset. If you use a data
reader to read directly from the database, you avoid the extra steps
required to manage the dataset.
Recommendations for Accessing Data
The following sections provide recommendations
for which data-access strategy to use with specific types of applications.
Web Forms
Use data commands in general; use a data reader
to fetch data. Because Web Forms pages and their controls and components are
recreated each time the page makes a round trip, it often is not efficient to
create and fill a dataset each time, unless you also intend to cache it between
round trips.
Use datasets under the following circumstances:
- You need to perform extensive processing with each record you get from the database.
- You want to work with multiple separate tables or tables from different data sources.
- If your data processing involves interdependent records.
- If you want to perform XML operations such as XSLT transformations on the data.
- You are exchanging data with another application or a component such as an XML Web service.
- If you prefer the ease of programming provided by datasets.
XML Web Services
XML Web services are ASP.NET Web applications,
and therefore use the same model as Web Forms pages: the XML Web service is
created and discarded each time a call is made to it. This suggests that the
data-access model for an XML Web service is largely the same as it is for Web
Forms. However, XML Web services are often middle-tier objects, and an important
part of their purpose is often to exchange data with other applications across
the Web.
Use a dataset if:
- Your XML Web service sends and receives data.
- For any of the reasons listed above for Web Forms.
Use a data command if:
- The XML Web service is performing a non-query operation, such as a DDL command.
- The XML Web service is retrieving a scalar value.
- The XML Web service is calling a stored procedure to execute logic within the database.
Windows Forms
In general, in a Windows Form, use a dataset.
Windows Forms are typically used on rich clients where the form is not created
and discarded with each user operation, as with Web Forms. Windows Forms
applications also traditionally offer data-access scenarios that benefit from
maintaining a cache of records, such as displaying records one by one in the
form.
Use a dataset if:
- You are using the Windows Forms data-binding architecture, which is
specifically designed to work with datasets.
- You are working with the same records repeatedly, such as allowing a
user to navigate between records.
- For any of the other reasons listed under Web Forms above.
Use a data command if:
- You are performing a non-query operation, such as a DDL command.
- You are getting a scalar value from the database
- You are getting read-only data to display in a
form — for example, creating a report. Stated differently, if there
is no need to keep the data available after accessing it, use a data
command.
| You must Sign In to use this message board. |
|
| | Msgs 1 to 18 of 18 (Total in Forum: 18) (Refresh) | FirstPrevNext |
|
|
 |
|
|
This article is extremely similar to this one from the MSDN Library:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconusingdatacommandversususingdatasets.asp
Is this an attempt to summarise the MSDN article, or a blatant copy?
|
| Sign In·View Thread·PermaLink | 5.00/5 (2 votes) |
|
|
|
 |
|
|
Another advantage to using SQL Commands is the ability to protect yourself against SQL Injection attacks. Since you can define your SQL Varible types and lengths your able to get strings treated as SQL Literals (not commands) and lessen your chance of Buffer Underrun Attacks.
------ What makes one intelligent? All things are equal; nothing. One who thinks one knows or has anything more than another is the greatest fool. Wisdom is the understanding and ability to accept you and all you know is nothing, equal to that of anyone or anything. Knowledge alone creates a blind fool. Are you wise?
|
| Sign In·View Thread·PermaLink | 5.00/5 (1 vote) |
|
|
|
 |
|
|
Hi, Should pass a Dataset to a method in another obj by ref or by value? For example, I have obj A and Library B. Obj A calls Library B, where B have a method to fill the dataset, and the dataset is bind to some control in A.
Thanks
|
| Sign In·View Thread·PermaLink | 2.00/5 (1 vote) |
|
|
|
 |
|
|
There shouldn't be a problem passing it by reference. As for the REASONS you would want to pass the Dataset around to different objects by reference, a good example would be if each object (being passed the Dataset) encapsulated a particular database connection. This way, you could have one Dataset object which could hold tables from all the data sources in the picture. Not a bad idea.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Following your text, can you say how one would create a "client side" dataset? With old-school ADO, you could create an ADO recordset completely through code (without any knowledge of any database) and populate it (say from some direct human data-entry) and persist it as XML and dump it into a message queue. From there, it could be pulled out and massaged some more, and later looped-through to be inserted into a real database in the end.
How to create a dataset all by itself so it can be populated any way I want?
|
| Sign In·View Thread·PermaLink | 1.33/5 (2 votes) |
|
|
|
 |
|
|
From the SDK documentation:
DataSet custDS = new DataSet("CustomerOrders");
DataTable ordersTable = custDS.Tables.Add("Orders");
DataColumn pkCol = ordersTable.Columns.Add("OrderID", typeof(Int32)); ordersTable.Columns.Add("OrderQuantity", typeof(Int32)); ordersTable.Columns.Add("CompanyName", typeof(string));
ordersTable.PrimaryKey = new DataColumn[] {pkCol};
|
| Sign In·View Thread·PermaLink | 2.00/5 (1 vote) |
|
|
|
 |
|
|
I agree that in a Web environment, the ADO.NET services must be used in a connect/transact/disconnect manner because web pages are stateless, but in a windows form application, I disagree. A Window's application can maintain the connection throughout the life of the application, which should (theoretically) improve performance.
Of course, the complexity comes in when you want the same code base to support both a web server side implementation and a stand alone client implementation.
Marc
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Marc Clifton wrote: but in a windows form application, I disagree. A Window's application can maintain the connection throughout the life of the application, which should (theoretically) improve performance
Surely that is still bad practice though? If you have a client/server windows app with lets say a 100 active users all keeping open their dB connections to the database won't that be bad for the db server?
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Well, how do you maintain a record lock in a multi-user system, say where you want to prevent multiple read or write access to a customer or patient file or some other multiple access sensitive data?
I haven't found any benchmark data, but I can't imagine that the server side of maintaining a connection is that costly--it seems like a socket, a handle, some space in a "lock file", and maybe some memory for buffering data. Marc
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
You implement your own record-locking - just a couple of columns in the table (locked_by + locked_at) which you update when you fetch the record for updating - you can run this as a quick data command when a user edits a value in the DataSet, e.g. 'update patient set locked_by = [user], locked_at = [now] where patient_id = [id] and locked_by is null and locked_at is null' - check the number of rows affected and if it's 0 tell the user they can't edit the record. Alternatively create a LOCKED table (tbl, id, by, at) with a unique index on tbl and id, and if the insert returns a unique violation error, same deal.
Maintaining open connections is annoyingly expensive, and even if the system can handle it with 100 users, what happens when you sell the same system (or one based on the same libraries) to a company with 1000 users?
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
OK, how expensive?
And besides, expensive to who? If it is expensive, then it should only be expensive to the server, and the server should be pretty beefy anyways, so where exactly does the problem lie?
Instead, consider the network traffic involved in opening and closing a connection.
I can't find any information on this topic. Do you have any sources that describe the mechanics of open/close, and resource allocations?
Not using the built in locking mechanism seems quite silly. Of course, the reason I used Oracle years ago was because it had row lock capability, while SQL Server only had table lock, making it rather useless.
Marc
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Sorry, I don't have any sources or figures on this, all I know is we had to recode a whole bunch of stuff to use connection pooling instead of maintaining client connections because the servers kept slowing down to a crawl. With pooling, there is minimal network traffic involved in opening and closing a connection, cos it only needs doing when a connection sits unused for long enough to get garbage collected.
Remember, just because the server should be pretty beefy doesn't mean it is. And even if it is, it won't be when they upgrade the MS software.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
I kinda agree with Marc.
Our team is (has to) adopting disconnected approach, but I don't understand why they didn't leave alternative (not counting use of ADO through COM).
Why is everything (technologies, application building blocks) based and explained with "SQL server resources (connections,locks,cursors) are very expensive..."?
Aren't we talking every day about cheaper memory, faster CPUs, bigger hard disks ?
Is it really time to "disconnect" ?
cheers, Davorin
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
I think Microsoft figured that in terms of future strategies, disconnected access would be the way to go, so they just threw their weight behind it. After all, as its already been pointed out, connected access is a nightmare when you're trying to make your application scaleable. Having the latest technology in hardware (i.e. "cheaper memory, faster CPUs, bigger hard disks") is still going to give way to best practices in programming, isn't it ?
|
| Sign In·View Thread·PermaLink | 5.00/5 (1 vote) |
|
|
|
 |
|
|
ADO.NET has that whole connection pool thing going on, so the performance hit from connecting and disconnecting is essentially nil anyway (he wrote, possibly naively).
|
| Sign In·View Thread·PermaLink | 2.67/5 (3 votes) |
|
|
|
 |
|
|
Microsoft advises to keep SQL connections as short as possible. With connection spooling opening new connections when really needed is less expenssive then keeping the server busy for not need.
|
| Sign In·View Thread·PermaLink | 5.00/5 (1 vote) |
|
|
|
 |
|
|
Anonymous wrote: Microsoft advises to keep SQL connections as short as possible.
Why? Evidence? How does an open connection keep a server "busy"? Geez, isn't it just some memory? What's going on behind the scenes?
I'd really like a link to some benchmarks that demonstrate this, one way or the other.
Marc
Latest AAL Article My blog Join my forum!
|
| Sign In·View Thread·PermaLink | 2.00/5 (1 vote) |
|
|
|
 |
|
|
Yes we may say that connections are automatically closed by .Net framework also there is connection pooling available that ensures the availability of Database connections but if in the case of Windows Forms if we don't have much issue of memory then i think there is no issue in using Datasets in Disconnected appoach as you know access to data from memory is faster than from database, if we can use Datasets in Windows applications we should do that, however in Web forms case is different and we use data readers and cashing, however we can use global Dataset object for data that will be accessed frequently by users in cases where data is of read only type and we don't need very uptodate data.
|
| Sign In·View Thread·PermaLink | 5.00/5 (1 vote) |
|
|
|
 |
|
|
General News Question Answer Joke Rant Admin
|