June's Course of the Month is now available! Every 10 seconds, a consumer gets hit with ransomware. Refresh your knowledge of ransomware best practices by enrolling in this month's complimentary course for Premium Members, Team Accounts, and Qualified Experts.
Course Of The Month
6 days, 19 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
I'm confused about binding controls to data sources in VB.Net
Posted on 2006-06-13
I have a question about binding controls to data sources in VB.Net.
First, my background is as an embedded guy and what you do there is allocate all resources, set things up, and hit the proverbial "go" button and then it just sits and spins until power is cut off.
I've read my Wrox book on VB, read forums on this site, read examples, am about half done my first VB-Sql server project and puzzled and puzzled about this whole "bound data control" concept.
Here's what I've puzzled out so far:
Ya got some controls on a form, with bindable properties that you "bind" to a data source, in my case either a DataSet or a DataView thats filled in with an SQL query. Great so far.
There's supposed to be a two-way-path that automagically causes changes to the data in the bound forms to be moved down into the DataSet when the user changes it on the form, and vis-versa. I'm a bit fuzzy on this part.
Sometimes, it seems, you have to re-bind your control to the data source. Not quite clear on just when you have to do this and why.
My Wrox book example rebinds the controls all the time. In fact, it seems that after each and every Update to the Database they re-fill the DataSets and rebind the controls. Now I'm confused. Dont controls stay bound? Do they come unbound somehow and need to be bound back again? Perhaps some super glue and bolts are needed here?
I'm cool on getting data into the DataSets and Views, thats just some SQLCommand objects and that makes sense. You issue a command against the DB, data in the DB changes. Update the DataSet, data there changes. But then there's this bound controls thing. If I must rebind after each update to the dataset, why bind at all?
Thanks.
First, my background is as an embedded guy and what you do there is allocate all resources, set things up, and hit the proverbial "go" button and then it just sits and spins until power is cut off.
I've read my Wrox book on VB, read forums on this site, read examples, am about half done my first VB-Sql server project and puzzled and puzzled about this whole "bound data control" concept.
Here's what I've puzzled out so far:
Ya got some controls on a form, with bindable properties that you "bind" to a data source, in my case either a DataSet or a DataView thats filled in with an SQL query. Great so far.
There's supposed to be a two-way-path that automagically causes changes to the data in the bound forms to be moved down into the DataSet when the user changes it on the form, and vis-versa. I'm a bit fuzzy on this part.
Sometimes, it seems, you have to re-bind your control to the data source. Not quite clear on just when you have to do this and why.
My Wrox book example rebinds the controls all the time. In fact, it seems that after each and every Update to the Database they re-fill the DataSets and rebind the controls. Now I'm confused. Dont controls stay bound? Do they come unbound somehow and need to be bound back again? Perhaps some super glue and bolts are needed here?
I'm cool on getting data into the DataSets and Views, thats just some SQLCommand objects and that makes sense. You issue a command against the DB, data in the DB changes. Update the DataSet, data there changes. But then there's this bound controls thing. If I must rebind after each update to the dataset, why bind at all?
Thanks.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
2
-
2
5 Comments
.NET provides a higher level of abstraction when using data and controls. Prior to .NET (i.e. with WIN32, MFC, or VB6 programming) you did something like this:
1) Create a control.
2) Open a data souce and read some records.
3) Stuff the data into the control.
.NET lets you do something like:
1) Tell your controls what data to get and from where.
Now if you do something that causes the database to change, like add, delete, or modify some records, the control is out of date and needs to be "refilled". So you tell them to do that. Why do you re-bind? You don't want the controls keeping the data connection open any longer than needed. So they close the connection when they are done getting the data they need. So you rebind to get them to go back to the database.
1) Create a control.
2) Open a data souce and read some records.
3) Stuff the data into the control.
.NET lets you do something like:
1) Tell your controls what data to get and from where.
Now if you do something that causes the database to change, like add, delete, or modify some records, the control is out of date and needs to be "refilled". So you tell them to do that. Why do you re-bind? You don't want the controls keeping the data connection open any longer than needed. So they close the connection when they are done getting the data they need. So you rebind to get them to go back to the database.
I think that about sums it up, and I agree with asker.
Another way to think of it could be that in networking, you may not be the only player in the nature of forming updates and how and when they are being done. An old rule was, whoever updates last wins.
Another way to think of it could be that in networking, you may not be the only player in the nature of forming updates and how and when they are being done. An old rule was, whoever updates last wins.
Ah.
I think I get it. Sounds to me that "rebinding" is something like "refreshing", like the refresh button on your browser. I was under the impression that once bound, controls would just keep themselves in sync whenever data changed. Clearly I was wrong.
So it sounds like the way to think about this is:
Keep your DataSets and DataViews in sync with the Database by issuing SQLCommands against the DB.
Book examples do this when user hits Save, Update, Delete, etc.
Keep your Controls in sync with the DataSets by rebinding after updating the DataSets.
I think I get it. Sounds to me that "rebinding" is something like "refreshing", like the refresh button on your browser. I was under the impression that once bound, controls would just keep themselves in sync whenever data changed. Clearly I was wrong.
So it sounds like the way to think about this is:
Keep your DataSets and DataViews in sync with the Database by issuing SQLCommands against the DB.
Book examples do this when user hits Save, Update, Delete, etc.
Keep your Controls in sync with the DataSets by rebinding after updating the DataSets.
>>controls would just keep themselves in sync whenever data changed.
I suppose that is possible and you could implement such a thing by deriving your own control from the standard ones but the overhead involved would be tremendous. In most cases you probably don't need to refresh the controls all that often and when they do need it, it is usually best to control when yourself.
I suppose that is possible and you could implement such a thing by deriving your own control from the standard ones but the overhead involved would be tremendous. In most cases you probably don't need to refresh the controls all that often and when they do need it, it is usually best to control when yourself.
OK, I get it now. This is "client-server" programming where the clients periodically asks the server for data and the trick is to keep the connection open as briefly as possible because there are very many clients and only so many resources on the server to handle them all.
Sounds like in this case, the controls are "clients" and the DataSets are "Servers" within the app and the app is a client to the database server.
Sounds like in this case, the controls are "clients" and the DataSets are "Servers" within the app and the app is a client to the database server.
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Computer science students often experience many of the same frustrations when going through their engineering courses. This article presents seven tips I found useful when completing a bachelors and masters degree in computing which I believe may he…
This article will inform Clients about common and important expectations from the freelancers (Experts) who are looking at your Gig.
Suggested Courses
Course of the Month6 days, 19 hours left to enroll
726 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.