When do you call DataGrid.DataBind()

[Water Cooler v2]

Sometimes, you call DataGrid.DataBind() after doing a

DataGrid.DataSource = DataSet (or reader)

and sometimes you don't. When is it that you have to call DataBind on
the datagrid and when is it not necessary? Why is there the difference?

 

[Scott M.]

You should call Databind on a DataGrid after any modifications to the grid's
data source (record added, deleted, updated, etc.)

As for sometimes calling databind after setting the data source and
sometimes not...Who said you should not be databinding after setting the
data source?

What you don't do is call DataBind in the Postback section of Page_Load.
The reason being is that the page is being reloaded for a reason. It could
have been that the user switch the page of data they want to see, the user
may have initiated a sort, the user may have deleted a row or updated a row.
All of these actions will force a postback. Page_Load will run early on in
the Postback process, so you'll want to set your datasource for your grid up
there, but don't databind here, because after Page_Load, the event that
caused the postback is going to fire (say the SortCommand event, for
example). If you bind in the Page_Load and then the SortCommand event
fires, you'd have to call DataBind again in the SortCommand event (because
you just changed what the grid is showing). So, on Postback's, you re-set
the grid's datasource in Page_Load, but put the Databind in the grid's event
handlers.

 

[Brian Tkatch]

You should call Databind on a DataGrid after any modifications to the grid's
data source (record added, deleted, updated, etc.)

As for sometimes calling databind after setting the data source and
sometimes not...Who said you should not be databinding after setting the
data source?

What you don't do is call DataBind in the Postback section of Page_Load.
The reason being is that the page is being reloaded for a reason. It could
have been that the user switch the page of data they want to see, the user
may have initiated a sort, the user may have deleted a row or updated a row.
All of these actions will force a postback. Page_Load will run early on in
the Postback process, so you'll want to set your datasource for your grid up
there, but don't databind here, because after Page_Load, the event that
caused the postback is going to fire (say the SortCommand event, for
example). If you bind in the Page_Load and then the SortCommand event
fires, you'd have to call DataBind again in the SortCommand event (because
you just changed what the grid is showing). So, on Postback's, you re-set
the grid's datasource in Page_Load, but put the Databind in the grid's event
handlers.

Who said you should not be databinding after setting the data source?

After setting a datasource, if i use the data adaptor's fill() command
to fill the dataset (which is the datagrid's datasource) there seems to
be no need for a databinding.

I've been wondering what it actually does, being i seem not to need it.

B.

 

[Scott M.]

There are 3 elements to making this work:

1. The actual data repository (a database?)
2. The in-memory representation of the original data (a dataset)
3. The user interface for the data (the DataGrid).

The original data needs to be replicated into the in-memory container (the
DataSet). This is accomplished by calling the .Fill() method of your
DataAdapter.

Now, the DataGrid needs to be "connected" to the in-memory data (the
DataSet). You must set the DataGrid's datasource property so it knows where
to get the data from, but just setting the datasource doesn't actually go
and get any data. So, you need to call the DataGrid's DataBind method to
tell the grid to go and look at the data (specified in the DataSource
property) and bind to it.

If the data in the DataSet ever gets changed in any way, or if you want to
show the existing data in a different way (a different page of data or a
different sorted view of the data), you are going to need to have the
DataGrid "refresh" its representation of that underlying data. Calling
DataBind does just that.

 

[Brian Tkatch]

There are 3 elements to making this work:

1. The actual data repository (a database?)
2. The in-memory representation of the original data (a dataset)
3. The user interface for the data (the DataGrid).

I think i will disagree with that. (Please correct me if i'm wrong!)

The in-memory representation, is actually an in memory copy. The
difference being, the copy changes, the original does not. And, this
copy is a datatable, not a dataset. A dataset is the container for one
or many datatables, however. (As well as dataviews and datarelations.)

The original data needs to be replicated into the in-memory container (the
DataSet). This is accomplished by calling the .Fill() method of your
DataAdapter.

Which just runs the .SelectCommand command. It would have been *much*
more clear had they named it "ExecuteSelectCommand" or
"SelectCommandResultsInto"

Now, the DataGrid needs to be "connected" to the in-memory data (the
DataSet).

It actually needs to be connacted to the dataview. If connected to the
dataset, it just shows a plus-sign which expands into the availible
dataviews, of which one must be selected to show any data.

Further, connecting it to a dataset leaves those arrows on the caption
bar. Connecting it directly to the dataview, however, does not.

You must set the DataGrid's datasource property so it knows where
to get the data from, but just setting the datasource doesn't actually go
and get any data.

Yep, that confused me at first. Which is when i realized that the
datagrid has absolutely nothing to do with a dataadaptor. A datagrid is
a window into the dataview. A dataview is the resultset of a datatable
(as opposed to the design). A datatable can be filled in many ways. One
way is with a select statement. One way to run a select statement is
via the Fill() command of a dataadaptor.

So, you need to call the DataGrid's DataBind method to
tell the grid to go and look at the data (specified in the DataSource
property) and bind to it.

When it is set it looks. Databind is not needed, as i expreessed
earlier.

If the data in the DataSet ever gets changed in any way, or if you want to
show the existing data in a different way (a different page of data or a
different sorted view of the data), you are going to need to have the
DataGrid "refresh" its representation of that underlying data. Calling
DataBind does just that.

Actually, calling datagrid.refresh does that.

I still see no reason for databind.

Hmm... unless it somehow "watches" it and refreshes for you.

As a note, calling Fill() works both before and after setting the
datagrid's datasource. That is, the FIll() command triggers the
datagrid to refresh. However, using .Expression() does not. If done
before the datasource is set, it shows the modified data, doing it
after the datasource is set, requires a datagrid.refresh for it to be
noticed.

Anyway, i see datagrid.databindings which requires me a to enter a
property name. I am a bit confused over exactly what this is.

BTW, i appreciate the help in clarifying this. I've got to read,
clarify, and test to figure this whole thing out. I'm still a bit
confused.

B.

 

[Scott M.]

I think i will disagree with that. (Please correct me if i'm wrong!)

The in-memory representation, is actually an in memory copy. The
difference being, the copy changes, the original does not. And, this
copy is a datatable, not a dataset. A dataset is the container for one
or many datatables, however. (As well as dataviews and datarelations.)

This is correct and does not conflict with what I said in the first place.
You've only expounded upon the structure of the DataSet, but for most
purposes of conversation, it is correct to say that the DataSet is the
in-memory representation, since the DataTable is in the DataSet.

Which just runs the .SelectCommand command. It would have been *much*
more clear had they named it "ExecuteSelectCommand" or
"SelectCommandResultsInto"

You'll need to pass that suggestion along to MS, but that doesn't change the
fact that calling .Fill() is how you populate the DataSet.

It actually needs to be connacted to the dataview. If connected to the
dataset, it just shows a plus-sign which expands into the availible
dataviews, of which one must be selected to show any data.

You only need to connect a DataGrid to a DataView if you want to see the
data differently than it is in the DataSet. You didn't mention that you
were in need or using DataViews, so I didn't go into setting the DataGrid's
data source to a DataView, but I have indicated that the DataGrid needs to
have its data source set to the in-memory representation of the data. If
that means DataView for you, then your data source is the DataView, rather
then the DataSet.

Further, connecting it to a dataset leaves those arrows on the caption
bar. Connecting it directly to the dataview, however, does not.

I'm not sure what you mean here. Are you using VS 2003 or 2005? Are you
talking about the WinForms DataGrid or the WebForms DataGrid?

Yep, that confused me at first. Which is when i realized that the
datagrid has absolutely nothing to do with a dataadaptor. A datagrid is
a window into the dataview.

Well, not always. A DataGrid is a window into the in-memory representation
of the original data. It could be a DataView or it could be a DataTable
directly or it could be a DataSet that holds a DataTable.

A dataview is the resultset of a datatable
(as opposed to the design). A datatable can be filled in many ways. One
way is with a select statement. One way to run a select statement is
via the Fill() command of a dataadaptor.

Not actually. A DataView holds no data whatsoever. It is simply a filtered
view of the in-memory representation of the data.

When it is set it looks. Databind is not needed, as i expreessed
earlier.

Again, I'll ask what version of .NET are you referring to? My responses are
based on the 1.1 Framework, VS.NET 2003 and the WebForms DataGrid. In these
versions, you MUST call .DataBind to get any data.

Actually, calling datagrid.refresh does that.

You are referring to the WinForms DataGrid aren't you? The WebForms
DataGrid does not have such a method.

I still see no reason for databind.

In a WinForms app, you would only need DataBind on the initial DataGrid
population.

As a note, calling Fill() works both before and after setting the
datagrid's datasource. That is, the FIll() command triggers the
datagrid to refresh. However, using .Expression() does not. If done
before the datasource is set, it shows the modified data, doing it
after the datasource is set, requires a datagrid.refresh for it to be
noticed.

Anyway, i see datagrid.databindings which requires me a to enter a
property name. I am a bit confused over exactly what this is.

BTW, i appreciate the help in clarifying this. I've got to read,
clarify, and test to figure this whole thing out. I'm still a bit
confused.

Good luck.

 

[Brian Tkatch]

I'm not sure what you mean here. Are you using VS 2003 or 2005? Are you
talking about the WinForms DataGrid or the WebForms DataGrid?

2003, winforms.

Well, not always. A DataGrid is a window into the in-memory representation
of the original data. It could be a DataView or it could be a DataTable
directly or it could be a DataSet that holds a DataTable.

Original? Why? AFAIK, the datagrid can change the data, now having two
sets, that are the orignal and the modified, and the datagrid shows the
modified.

Not actually. A DataView holds no data whatsoever. It is simply a filtered
view of the in-memory representation of the data.

Granted.

However, setting it to a datatable is the same thing as setting it to
the datatable's defaultview.

Again, I'll ask what version of .NET are you referring to? My responses are
based on the 1.1 Framework, VS.NET 2003 and the WebForms DataGrid. In these
versions, you MUST call .DataBind to get any data.

Ah, well, that explains it.

It's all so confusing.

In a WinForms app, you would only need DataBind on the initial DataGrid
population.

Nope. You never need to do it on winforms.

I read some more about it. The purpose of databindings has to do with
controls and returning values, like the bound column in Access. So, for
example, if a combo box shows one column but returns the value of
another, a databinding would need to be done to the column whose values
are wanted.

B.

 

[Scott M.]

Original? Why? AFAIK, the datagrid can change the data, now having two
sets, that are the orignal and the modified, and the datagrid shows the
modified.

But after modifying the datagrid (which modifies the in-memory
representation of the original data) wouldn't you want that in-memory
representation to update the original data (thereby putting the two back in
sync)?

 

[Brian Tkatch]

But after modifying the datagrid (which modifies the in-memory
representation of the original data) wouldn't you want that in-memory
representation to update the original data (thereby putting the two back in
sync)?

If the user likes the changes, yes. Otherwise, no.

B.

 

[Scott M.]

Either way, the grid's data source and the original data will need to be
in-sync.

Either both have the new/edited data or both remain unchanged.

Updating the grid should update the original data and if that succeeds, the
grid's data source should be updated.