To Bind or Not To Bind? 1

[CajunCenturion]

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

 

[CCLINT]

Why would you bind controls to a recordset?
I would never do it!

Why would you not bind the controls to a recordset.
I would!

While I am limited to as what can be said, I will say that a recordset is not necessarily an object that returns records from a datasource.

Think about it. Full control is there.

 

[CCLINT]

Sorry, I worded that wrong:

Why would you bind controls to a recordset?
I would never do it!

Why would you bind the controls to a recordset.
I would!

What I meant to say is that I would never do it the classical way - there is no control there. I would never bind them to a database.

It depends on what the word "Bind" means to you - what perspective you are viewing the bind at. To me, bind doesn't mean a change in the control directly affects the data in the database.

As I said above, I am limited to as what can be said.

But, what is an ADO recordset, or rather, what can a ADO recordset object be, or what can be done with one.
It is just an object..a collection of objects, which holds information for you?.


Use it to your advantage.

 

[Guest_imported]

We are not in the days of old anymore, where bound controls were as useless/restricted as a car with-out wheels, (or ones that always fell off). Reach under the seat and you will find some hidden buttons that will cause that same earth bound car - which at the first glance looks the same as it did before, and still has wheels falling off - to soar off the ground.
You can! control all! data going to and coming from bound controls, any time, every time, and mostly better and faster than any other way. And best of all, they do not have to even be bound to a database----until you! (not the control) are ready to get or send the data.
The 2 tier way with bound controls is a thing of the past...

 

[RichS]

unborn,
If you have the need to store those profiles you allowed your users to create you would need a database, if even a simple one like in a text file.

And for SQL and Access you do need a program to set them up and manage them. For example in Access you would create a table with fields for data. Access exposes these so that VB can read from and write to the table.

Give it a try.

 

[zemp]

I think CCLINT has a point on what binding means to you. I have always thought of binding as setting up the control at design time and that's it. Maybe this is an outdated view. Probably because I don't bind controls and haven't for years. Why? I'm not sure, probably I have gotten too comfortable in using the same or similar controls in an unbound fashion. Maybe I haven't given the new VB bound controls a chance.

So, those who advocate binding controls enlighten me!

First, let me play devils advocate for a while. I have a problem with the following statement. "You can! control all! data going to and coming from bound controls, any time, every time, and mostly better and faster than any other way. And best of all, they do not have to even be bound to a database----until you! (not the control) are ready to get or send the data."

What does mostly mean? Is there an unbound method that is better and faster, if so why bother with binding the controls?

"And best of all, they do not have to even be bound to a database" Does this part of the statement advocate unbound controls? From my point of view if you are setting the datasource or recordsource property at runtime then the control is unbound, but that might just be my outdated view.

The bottom line is that I believe that there is a place for both binding and not binding. The question shouldn't be which is best but rather which best suits your current needs, or your current skill set.

Looking forward to your comments.

Thanks and Good Luck!

zemp

 

[unborn]

RichS:
yeah i saved them more or less as a text file... and use a file folder to have a list of saved profiles its sort of nice but i was talking more of the stuff in the properties data control things -shrug i wouldnt know how to use them or what it would take hehe

in the begining man created code.
in the end code will create man.
clones are coming only matter of time.
examples?

http://planetsourcecode.com