Fog Creek Software
Discussion Board




Bound data controls

I don't normally do database programming, but I've been thrown into a project that requires me to come up to speed on .Net DB basics.  We're going to develop two sets of UI's. One will be a desktop app for a few power users.  The other will be a web app for general user data entry, editing, and reporting.

So I've been doing some reading most of what I've come across has covered bound data controls.

I always thought that these were a no-no since they tied up network bandwidth with every open database connection.  Is that still true, or has Microsoft found a way around this, opening a connection only when needed.

In general, are there any guidelines as to when it's appropriate to use disconnected recordsets and when to use bound data controls?

anon
Friday, November 14, 2003

As near as I can tell, you can do both. That is you can create a 'DataSet' which is disconnected copy of the data and then bind your controls to the DataSet.

It looks to me like you need a Connection object, a DataAdapter object and a DataSet object (which can contain one or more DataTable objects, complete with relations, etc.). Handled properly, the DataAdapter will take care of opening and closing the connection when you call the various methods associated with data access (Select, Update, Insert, Delete).

I'm only just getting started with this myself, but that's how I interpret the help topics I've read as I try to build/debug my app. Just so you know, things actually seem to be working and I know that I've never explictly opened anything (which I realize is not quite the same as not having *actually* opened anything).

Ron Porter
Friday, November 14, 2003

Yes you want to do both.  "Bound" controls are linked to a data provider ie a recordset.  Whether or not the recordset is connected all the time is up to you.

By being "bound" a lot of things happen automatically like loading of the values.  Using disconnected recordsets a good to save server resources.

DJ
Friday, November 14, 2003

The issue with "bound" controls was from the VB5/6 days where binding a grid to a database table or view meant the user was operating directly on data, you had no control over events, validation was hard, etc.

.Net binding isn't quite the same animal, as you're binding to a datasource you control and populate, which obviates a LOT of those problems.

HTH,
Philo

Philo
Friday, November 14, 2003

Hey, great replies. really cleared things up. Philo you were right on about VB5/6 stuff - that's where I did the previously little db coding before.

OK, now on to my disconnected recordset questions.

Can I lock records while I'm disconnected?  It's unlikely that any 2 users would ever be editing the same record at the same time, and if they were it would likely be different fields in the record. But being lazy, I was just going to write back the whole record at a time, instead of tracking dirty fields and just updating those.

So, what the best way to handle this?

anon
Friday, November 14, 2003

What happens is that you reconnect the dataset to the database and call the update method.  The provider then determines whether or not the records being updated are in a locked or edit mode.  If you opened the record set pessimistically then the records are locked and the data provider will throw a "Record Locked by user on machine" error which you can trap.  If you opened the record set optimistically you will recieve a "Record has been changed by user on machine since you started updating".  You can trap this error also and ask if the user wants to retry and perhaps show them the data that they are about to change.


Friday, November 14, 2003

If you're in VS.Net, use a typed dataset - all the concurrency code is built in.

Read
http://www.15seconds.com/issue/030317.htm

Philo

Philo
Friday, November 14, 2003

*  Recent Topics

*  Fog Creek Home