 |
|
 |
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 | 3.00/5 (2 votes) |
|
|
|
 |
|
 |
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) |
|
|
|
 |