|
-
Apr 22nd, 2007, 06:23 PM
#1
Thread Starter
Hyperactive Member
[RESOLVED] VB .NET truely a different beast- Data Binding
Along my short travels in .NET 2.0 and CF 2.0, I have learned many things that look and operate similar to VB6. But many things that seem fimilar are actually quite different. So for practical purposes I have abandoned VB6, except for troubleshooting existing apps. I am redeveloping all critical apps in .NET, what a better way to learn, correct?
At the moment I am learning to work with the Datagrid control. It seems to be a much more robust control than the flexgrid controls in VB6. But I also keep seeing the terms "data" and "binding", and they keep bringing haunting voices back from the past about data bound contols.
In VB6, I would use a subroutine to parse a dataset and then adjust the column width, color the rows, load the data into the cells, etc. Nothing was actually bound to the list view because I was taught that data bound controls were evil and dangerous.
The newer controls seem to be binding to DataAdapters and TableAdapters, etc. Hence they are quite different beasts to work with as well.
Are these controls in .Net evil, or have they been revamped to allow disconnected snapshots of data to be loaded in to controls, etc where the datasource is not directly bound to the database?
Or is the terminology just confusing me.... Looking for a little insight... Thanks.
-
Apr 22nd, 2007, 07:06 PM
#2
Re: VB .NET truely a different beast- Data Binding
Data-binding in VB.NET is quite different to data-binding in VB6. The main premise of ADO.NET is that it works disconnected. Once you retrieve data from your database it is immediately stored as a local copy with no direct connection to the original database. It is that local copy that is involved in data-binding. Data-binding itself is a mechanism for reducing the amount of code you have to write to keep your local data store and your UI synchronised. You should use it wherever it can help you. It is not appropriate to use data-binding in all situations and it cannot do everything, but it is a big time-saver and can help you avoid errors that might creep into your own code if you handled all the data synchronisation yourself.
-
Apr 22nd, 2007, 09:37 PM
#3
Thread Starter
Hyperactive Member
Re: VB .NET truely a different beast- Data Binding
Ok. Thanks.
That is what I derived from my reading. I am still not clear what happens in a multi-users enviroment. What is done, or needs to be done to ensure that your local data is still accurate by the time the user is done working with the locally cached recordset? How would you know what records may have changed while another user may editing the same record.... I guess really making sure the data is consistent, since you are not locking records, etc...
-
Apr 22nd, 2007, 09:49 PM
#4
Re: VB .NET truely a different beast- Data Binding
When the IDE creates your SQL statements it uses optimistic concurrency by default. It will test each record before making any changes to ensure that no changes have been made since you retrieved the data. If your data is not consistent than an exception is thrown. It's up to you to decide how that exception is handled. You might notify the user and ask them whether they want to view the new version of the data or just proceed regardless. You may prevent them from making any changes to inconsistent data. It depends on the context so it's up to you to decide.
-
Apr 23rd, 2007, 12:13 AM
#5
Thread Starter
Hyperactive Member
Re: VB .NET truely a different beast- Data Binding
That makes sense. Things are coming along, a better understanding seems to make things go smoother. Thanks for the detail explanation.
I can open a database connection and fill a DataAdapter with a set of records, but I now need to format the columns, etc.
So here is a basic run down of the procedure....
1) Create a DataTable
2) Create a DataAdapter
3) Open a connection to the database
4) Connect DataAdapter to record source
5) Fill the DataTable with data retrieved by DataAdapter
6) Close the connection
Now the records selected are loaded in a DataTable. Alternatively, if the data can simply added to rows in the DataTable if a database connection is not need, ie a static info in a DataGrid, etc. Now to format the columns of the DataGrid.
7) Create a TableStyle to which ColumnStyles will be added
8) Add ColumnStyles for each column that will be displayed in DataGrid
9) Optionally, the TableStyle can use AlternatingBackColor setting???
10) Set the TableStyle for the Grid, then fill the DataGrid with newly added Column Types with data stored in DataTable.
Is this method a step in right direction to creating a formated DataGrid populated with data? I think I need to a a class to do some of this formating.
-
Apr 23rd, 2007, 12:46 AM
#6
Re: VB .NET truely a different beast- Data Binding
If you're using .NET 2.0 then the DataGrid is essentially obsolete. Use the DataGridView that you'll find in the Toolbox. All that TableStyles and ColumnStyles stuff is irrelevant for the DGV. It's options are much more extensive and, while some complexity is inevitable, its formatting options are much better.
-
Apr 23rd, 2007, 01:55 AM
#7
Thread Starter
Hyperactive Member
Re: VB .NET truely a different beast- Data Binding
Damn, and I just spent 2 hours learning the DataGrid demo.... haha. Oh well, can't say I didn't learn anything.
Does the DataGridView port to CF 2.0, or must I still use the DataGrid there?
-
Apr 23rd, 2007, 02:24 AM
#8
Re: VB .NET truely a different beast- Data Binding
Doesn't look like the DGV is in the CF.
-
Apr 23rd, 2007, 07:27 AM
#9
Thread Starter
Hyperactive Member
Re: VB .NET truely a different beast- Data Binding
I opened another thread in the Mobile Dev forum. Maybe a Listview control would work better than DataGrid since DataGridView is not available.
Thanks.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|