Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

To Bind or Not To Bind? 1

Status
Not open for further replies.

CajunCenturion

Programmer
Mar 4, 2002
11,381
0
0
US
We haven't had a good theoretical discussion in a while, so I thought I'd pop this question out to get some action.

Should you bind your controls to your datasets? Why or Why Not?

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
 
Cajun, you suprise me by bringing up this topic. I never bind a thing, because I like to control the data. The only good thing I can say about binding is that it works great as a learning tool. Any other use is strickly out of the question due to lack of control and the fact that it tends to promote sloppy code writing and laziness. For example, I had an app dumped on me that had about 35 bound controls on it for each of the desired recordsets[evil] and then a whole load of code to control the visibility of the data grids and combo boxes. (I almost quit my job over this stunt) Never the less I cut the final exe size to almost 1/8 the size and had 1 connection with only about 5 controls for the user interface. I guess I will leave this alone for now, I just wanted to get things started. [peace] If you choose to battle wits with the witless be prepared to lose.
[machinegun][hammer]
 
I don't bind either - I want to be in as much control as possible over whatever I'm using.

I was just hoping to get a nice discussion going. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
 
I think foada hit the nail on the head. Binding is fine when you are learning VB and databases, or if you have a simple program that has a database that is read only, but it's very restrictive in that you have to give up a lot of your control over the data and when it is refreshed. Not to mention the things you can't do with bound controls.

MS should have spent more time and effort on other things that could have enhanced VB, instead of putting data bound controls in it.

Robert
 
BIND ???

Whats that then other than numerous 'Type Mismatch' whenever the user tries to enter data before you can trap the error, Controls connected to the wrong database when you enter UAT/Live environments, the list is numerous.

In a word Never have and Never will use them.

Chris Dukes
 
I am new to databound controls and even i can see that binding these controls to a data source it seems to be point less this method goes against the concet of OOP why have many different controls bound to different data sources when you can have 1 that can be used for all recordsets.

Just my opinion
 
Binding? I tend to avoid it unless I'm knocking up a very quick proof-of-concept.
 
Obviously, this was not a good choice upon which to begin what I hoped would be an interesting discussion with varying opinions.

Anyone have any ideas? Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
 
strongm,

That would probably lead to the same type of discussion:
No, we all tend to aviod variants if possible, because they blur what is actually happening with implicit casts - and numerous other reasons... Sunaj
'The gap between theory and practice is not as wide in theory as it is in practice'
 
Just let me get this straight....

"Bound" Programming means:

Set Me.myTextControl.DataSource = rsADO
Me.myTextContro.DataField = "myTextField"

while "unbound" means a manual refresh like:

Me.myTextControl.Text = rsADO![myTextField]

And the later is prefered because you can write back the data whenever you like...? Correct?
 
waldemar,

Bound means that the control is "bound to a data source" using the datasource, datafield etc. properties for the control. This limits the data displayed in the control. If you would like to learn more about this look up the Data Bound list control in MSDN. If you choose to battle wits with the witless be prepared to lose.
[machinegun][hammer]
 
So everybody prefers

Me.myTextControl.Text = rsADO![myTextField]

over

Set Me.myTextControl.DataSource = rsADO
Me.myTextContro.DataField = "myTextField"

? (Doesnt that slow down the program...? While ADO bound fields might use closer routines to the system for updating the screen, I have to all that stuff manually....)
 
waldemar
I don't bind for several reasons - the first being one of control. I like to be in control. Just because a text box is being updated, doesn't necessarily mean that I want the Recordset being updated - there may be data dependencies, or error checking that must come into play. I also can restore a text box back to its original value, because the recordset doesn't get updated, until I know that the database is to be updated.

With unbound controls, I also have the flexibility to control the format and display. One example that comes to mind is I can copy the data from a RecSet to the FlexGrid and apply various functions and/or formatting rules to the data, based on values, to customize the display.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
 
To be honest, I think that databinding is one of those areas that takes some education to understand (and it is nice to find a dissenter in the ranks).

For many, many moons I quite happily used bound data controls. It was only when I started getting frustrated about the level of control, combined with some odd errors, that I started questioning the idea (no matter how many people said "don't do it")

The point being that, no matter how many of us give the same advice (i.e "don't do it") based on bitter experience, it seems clear that there is a place for it, and that most of us have used it at some point.
 
I agree strimg, there is a place for it. I am not professing the you shouldn't do it, but rather, that I choose not to do it, for many of the reasons previously stated. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
 
Geez, I am sorry for misspelling your handle strongm. Maybe I should bind my fingers to the keyboard.
Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
 
yay ive been programign for like 4 yrs.. and still have no use for databasing crap so i have no earthly idea what yr talking about.. well accually i think i have a CLUE but oh well.. i mean i love visual basic.. but i sort of feel it a waist of my brain.. i have done nothign splended with it. i work for no one and ive taught myself all i know. no schooling and such. jobs are out of question because i know i lack alot of knowledge.. and i still cant find a reason why i would even bother with databases.. hah what so i could store my friends addresses in them? eek no good i lack those seeing im a computer junky haha.. perhaps oneday soemhtign will arise where i will have to learn it.. and i look forward to that day.. cause man.. i get depressed sometimes on how my knowledge of vb goes to waist.. out of my 4 years of programing ive managed to make one successfull program.. and it is from so site to help the users make nice profiles.. which was accually fairly easy to make even though i did put countless hours into maken it. -sigh. i hope one day ill have use for this knowledge in my head..


side note... SQL and Access and or Excel databases.. do you need a program to use these or somehting? or can i just umm make databeses for them out of thin air.. and do the users have to have the probrams?

im ageezer in years but a newb at heart haha.


thanks for listening to me rant and rave about my uselessness haha.. hope umm this helps liven up your topic Caju :) hehe in the begining man created code.
in the end code will create man.
clones are coming only matter of time.
examples?
 
>i still cant find a reason why i would even bother with
>databases

Well, here in the UK well over 75 percent of advertised VB jobs seem to require some sort of database knowledge as well.

>can i just umm make databeses for them out of thin air

Yep, more-or-less...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top