Is databinding of any use.......

Moorzee

Well-known member
Joined
May 31, 2006
Messages
92
Location
England
Programming Experience
3-5
.....to anyone in the real world at all? Started to use it and thought 'yeah, sweet. All my updates done for me no more tedious insert/update script writing for me.'

As soon as you introduce a 2nd table into the dataset you're knackered. What poxy app would only ever be accesing/updating data from one table only ever?

A pointless addition in my eyes. More agro than it's worth or am I utterly wrong?

Back to populating controls manually and nice simple insert/update routines for me.
 
Whilst i'm sure there will be a wide difference of opinion on this topic. Here's my 2 cents. I dont like databinding, and i don't use it. I once read an article that was titled 'Why DataBinding Is Evil, Use ADO Instead' Evil? well probably not, but just a pain in the butt in my opinion. I've always done it manually, and it's what i'm used to. So Moorzee, i'm with you on this one.
 
That article was about data-binding in VB6 which, like so many things in VB6, was a pain. Data binding in VB.NET has virtually nothing in common with data binding in VB6 bar the name, just like ADO.NET is very different to ADO.NET. Data binding in VB.NET is a good thing and it is very useful. Sorry Moorzee but you just aren't doing it right. Do you really think that it would only be possible to use data binding with a single table? You can bind all sorts of data to all sorts of controls. That data doesn't have to be in DataTables either, but if it is you can bind as many different tables to as many different controls as you like.
 
I have to echo the sentiments of jmc - I used to think that databinding was the most vile, evil thing in the world. Until .NET rolled out.... now that databinding works the way I think it should, it's been a god send. Any you know what else? You don't //have// to bind to a dataset/table.... you can bind to **any** bindable object... even your own objects (been there done that, and man did it save time in development.) What I haven't gotten into is the concurency manager and being able to "scroll" through my objects (as I tend to deal with a single object at a time and not lists.)

Databinding becomes a problem when it is missused and misunderstood. It's not the be-all, end-all... but a tool of the trade.

-tg
 
Oh go on then you lot, gang up on us!!!:) I know that deep down, that i could have used databinding, and it probably would have cut the amount of typing i've had to do by a noticable amount. It's just that i never have used it, i can do everything i need to do without it. But fair do's, i'm not trying to say that you shouldn't use databinding, it's just another one of those ones where you get used to doing things a certain way:cool:
 
Don't knock it until you've tried it.
Here's another neat little trick I learned to make databinding even easier. When I put a control on my form that I am going to databind, I put the object name and property name in the .Tag property of the control. Then I've got a routine that runs after my object is filled. The function loops through all controls and for any control with it's .Tag property set, binds that control to the appropriate object/property. This way I can add/remove controls & binding at will w/o changing any code. My next objective is to make it DB based... letting my database determine what is bindable and what isn't....

-tg
 
The use of the BindingSource as an intermediate step in .NET 2.0 makes life easier too. If you always bind controls to a BindingSource and then bind your data, in whatever form it takes, to the BindingSource then you will always have the simple and consistent interface of the BindingSource to work with. Given that the BindingSource has properties for filtering and sorting, plus methods for add and removing, that makes dealing with disparate types of data much easier. Even if you use DataTables as your data source 95% of the time, in my opinion the BindingSource makes things easier. Navigation becomes a matter of:
VB.NET:
Me.BindingSource1.Position += 1
 
jmcilhinney said:
Do you really think that it would only be possible to use data binding with a single table?quote]

So what am I doing wrong then? I bind all controls sweet as a nut but as soon as I bring back another table into the dataset then my updates (built by commandBuilder) go to pot. Some message regarding updates can only be created from dataset or adapter with single table.

Sometimes I don't have all the data in one big sweaty unnormalised table. ;)

What should I do instead?????

Chaars.
 
Moorzee said:
jmcilhinney said:
Do you really think that it would only be possible to use data binding with a single table?quote]

So what am I doing wrong then? I bind all controls sweet as a nut but as soon as I bring back another table into the dataset then my updates (built by commandBuilder) go to pot. Some message regarding updates can only be created from dataset or adapter with single table.

Sometimes I don't have all the data in one big sweaty unnormalised table. ;)

What should I do instead?????

Chaars.
That's got absolutely nothing whatsoever to do with data-binding. The IDE cannot automatically generate SQL code from a query that involves a join. How could it? If the data comes from more than one table how would it know which one to make the changes to? If your query involves a join then you have to write the SQL code to delete, insert and update yourself, but none of that has anything to do with data-binding.
 
Ok, I'll sack the cmdBuilder arg then if you think it's unrelated although I disagree. Why would I bring back data, then want to update if it by using cmdBuilder if it had not changed, and most changes occur on a data entry/amendment form? But thats by the by.

Databinding. I have a form with a tabstrip with 4 tabs. I bind controls on the different tabs to a ds and they only get populated when they are made visible, i.e I have to select each tab at run time before I can do anything at all with the bound controls data? Poor.

Also I'd say the cmdBuilder could update across mutiple tables if joins were present providing the table was qualified before column name?
 
*sigh* What does a CommandBuilder have to do with data-binding? You use a DataAdapter to retrieve data into a DataTable. A CommandBuilder is used to generate SQL statements to save changes to that data back to the database. That has absolutely nothing to do with WinForms controls. You can get data, change it and then save it in a Console app, but you certainly can't data-bind. As for data-binding, you can bind all sorts of data to controls. It doesn't have to have come from a database and it doesn't have to be in a DataTable. The two things often work together because it is often desirable to get data from a database, display it, let the user edit it and then save it, but they are two completely separate operations.

As for your issue with the CommandBuilder, it doesn't matter if you have qualified your columns with the table name. A DELETE, INSERT or UPDATE statement can only affect one table. If your query involves two tables is the CommandBuilder to arbitrarily decide which one it should make changes to? Of course not. You have to specify which tabel or tables you want to affect by explicitly coding the SQL statements yourself.

Finally, the bit about the TabControl is interesting. It doesn't happen with complex data-binding, like with a DataGridView, but does with simple data-binding. I tested it to see and you are quite right that that is the case, but I quickly came up with a work-around. I just put the following code in the form's Load event handler:
VB.NET:
For Each tab As TabPage In Me.TabControl1.TabPages
    Me.TabControl1.SelectedTab = tab
Next

Me.TabControl1.SelectedIndex = 0
Now that all tabs have been selected any binding you do takes effect immediately, even if it is done after the Load event handler has completed. That's a bug, yes, but it's an easy one to get around, so you shouldn't be so quick to bag something and a little quicker to think about how to fix the small issues that exist.
 
ok, ok. I've been looking at databinding from my own perspective and tarring everything(combuilder) with the same brush. I was using databinding to populate all textboxes/combo's etc then wanting to update nice n easy. It aint all it's cracked up to be in my opinion.

ComBuilder uses dataAdapter. DataAdapter populates dataset. Controls are bound to said dataset. Why if the control is bound to data retreived via a join can it not be updated? If the databinding is clever enough to know where the data came from and whether it has changed, surely the builder can find out what to update? If it has been returned by a query there is a join method! Why can it not reverse eng back to what needs changing?
 
Moorzee, you are determined not to hear what I'm telling you so I'm going to give up after this. CommandBuilders and data-binding are UNRELATED. The fact that you're trying to force some sort of relationship just proves that you don't understand them. CommandBuilders cannot generate SQL code from a query that contains a join. The fact that you are trying to force them to just proves that you don't understand them. Data-binding is not a panacea, but it is an extremely useful tool. If used properly in a great many cases you will never have to touch the data in code. You simply retrieve it and save it and data-binding does the rest. The fact that it's not for you just proves that you don't understand it. Not understanding something is no crime, but if you doggedly cling to this notion that everything should work the way you want it to, even though what you expect doesn't actually make logical sense, then you will never gain an understanding of how these things do work. You need to set aside your preconceptions and open your mind a bit.
 
Chill Jmc......
Bloominheck lad. I know that the cmdbuilder does not create updates/inserts/deletes where a join exists in the stored proc. All's I was saying was that it should be able to! Also even if no join exists, if I simply populate another table in a dataset which has been filled by a dataadapter then a cmdbuilder used against the da updates fail? It does'nt make sense to me!

You are correct also, I don't fullyunderstand how the components work but should I need to? Abstraction should mean I don't need to know no?

Anyway cheers and calm down. :rolleyes:
 
Moorzee said:
I was saying was that it should be able to!
No they shouldn't. There is no way that it could possibly happen without an arbitrary decision being made about which of the tables involved in the join should be affected by the SQL statements generated. If you are happy for your code to perform arbitrary actions then I'd be very concerned about the quality of your software.
Moorzee said:
if I simply populate another table in a dataset which has been filled by a dataadapter then a cmdbuilder used against the da updates fail
That is absolutely false. CommandBuilders neither know nor care anything about DataSets or DataTables. All they know about is the DataAdapter and the CommandText of its SelectCommand. That is the ONLY thing affects their ability to generate SQL statements. If the query is ambiguous in the sense that it is not definitive which table should be updated then the CommandBuilder cannot generate SQL statements because it would have to make arbitrary decisions. The only other thing that is a factor is whether the DataAdapter retrieves primary key information from the original table. If the table has no primary key or the DataAdapter does not retrieve primary key information then the CommandBuilder cannot generate SQL statements, again because it would have to make arbitrary decisions. Without a primary key the CommandBuilder has no way to uniquely identify each record.
Moorzee said:
I don't fullyunderstand how the components work but should I need to? Abstraction should mean I don't need to know no?
You don't have to fully, or even partly, understand HOW things are done, although the more you do understand the better equipped you will be to make good development decisions. You should, on the other hand, strive to fully understand WHAT can be done. If something can't be done and you think it should, then understanding how things are done is the way for you to be able to either implement it yourself, ot else realise why it can't be done in the first place. There is no way that a CommandBuilder can automatically generate SQL statements from a query that involves a join. If you understand how a CommandBuilder, and some of the other data access classes, works then you know why this is the case. It is simply not possible without making some arbitrary decision and computers are not capable of that. They always have to be told what to do. If there are multiple tables that could be updated then you have to tell it which one to update. The CommandBuilder cannot simply choose one.
 
Back
Top