471,089 Members | 1,130 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,089 software developers and data experts.

GridView - I've gotta be missing something...

I have a simple winform with a customers combobox, a "get orders"
button and an orders grid. Due to other requirements, I have
implemented the form to allow the user to select a customer from the
combobox and click the "get orders" button to refresh the gridview with
the selected customer's orders, via a GetDataByCustomerID stored
procedure.

The underlying Orders table includes, among others, three boolean
columns and one particular datetime column, all of which are set to NOT
NULL with default values. All of these columns have valid values
specified in the table, yet when I call the stored procedure to refresh
the grid, I get validation errors for those four columns and their data
does not display. The other columns display just fine.

As I mentioned, I'm getting this data from a stored procedure. The
stored procedure *does* return the values for those four columns. The
gridview for some reason sees those columns as having null values or
something.

I have completely deleted the form and recreated it. I have completely
deleted the dataset and recreated it. Neither had any effect. Each time
I redesigned it, the problem was present. Does the gridview have issues
with required values? Even if it did, shouldn't using a stored
procedure get around that?

I'm running out of things to try here. Any advice would be much
appreciated.

Rich

Jul 25 '06 #1
3 1866
Hi Richard,

I assume you are referring to the DataGridView control?
gridview for some reason sees those columns as having null values or
something.
Check your in-memory DataSet after binding to verify that there is actually data in the appropriate rows/columns by setting a break
point in code, attaching a debugger and viewing the object in a watch window.
I have completely deleted the form and recreated it. I have completely
deleted the dataset and recreated it. Neither had any effect. Each time
I redesigned it, the problem was present.
I suspect that your problem might lie in your data access code. See first if the DataTable to which your DataGridView is bound
contains the appropriate data after binding as I mentioned above.
>Does the gridview have issues
with required values?
Not that I'm aware of. Binding to Boolean and DateTime columns with AllowDBNull set to false has always worked in my experience
even when the DataGridView implies the columns from the schema of the data.
Even if it did, shouldn't using a stored
procedure get around that?
No. How the data gets into a DataTable has nothing to do with how the DataGridView handles reading and displaying the data. The
key here is to make sure the data, in memory, is what you expect. If it's not then go from there.

--
Dave Sexton

"Richard Carpenter" <ru*******@hotmail.comwrote in message news:11*********************@m73g2000cwd.googlegro ups.com...
>I have a simple winform with a customers combobox, a "get orders"
button and an orders grid. Due to other requirements, I have
implemented the form to allow the user to select a customer from the
combobox and click the "get orders" button to refresh the gridview with
the selected customer's orders, via a GetDataByCustomerID stored
procedure.

The underlying Orders table includes, among others, three boolean
columns and one particular datetime column, all of which are set to NOT
NULL with default values. All of these columns have valid values
specified in the table, yet when I call the stored procedure to refresh
the grid, I get validation errors for those four columns and their data
does not display. The other columns display just fine.

As I mentioned, I'm getting this data from a stored procedure. The
stored procedure *does* return the values for those four columns. The
gridview for some reason sees those columns as having null values or
something.

I have completely deleted the form and recreated it. I have completely
deleted the dataset and recreated it. Neither had any effect. Each time
I redesigned it, the problem was present. Does the gridview have issues
with required values? Even if it did, shouldn't using a stored
procedure get around that?

I'm running out of things to try here. Any advice would be much
appreciated.

Rich

Jul 25 '06 #2
Thanks, Dave. I'll look into that, and yes, it is the DataGridView
control that I am using.

Additionally, and forgive me for the basic question, as I am still
fairly new to ADO.Net, but I have tried accessing the data in my
DataTable before and had little luck. The object model still confounds
me to some extent. Should I drill down into the actual DataTable object
to view the data, or go through the BindingSource? If the DataTable, I
assume it starts at DataSet.DataTable...?

Also, and you can save me another thread here, when referencing that
data, how can I determine which row is current as seleted in that
DataGridView? My assumption was to look into the BindingSource object,
but I have similar questions there as with the DataTable.

Thanks for your time.
Rich

Dave Sexton wrote:
Hi Richard,

I assume you are referring to the DataGridView control?
gridview for some reason sees those columns as having null values or
something.

Check your in-memory DataSet after binding to verify that there is actually data in the appropriate rows/columns by setting a break
point in code, attaching a debugger and viewing the object in a watch window.
I have completely deleted the form and recreated it. I have completely
deleted the dataset and recreated it. Neither had any effect. Each time
I redesigned it, the problem was present.

I suspect that your problem might lie in your data access code. See first if the DataTable to which your DataGridView is bound
contains the appropriate data after binding as I mentioned above.
Does the gridview have issues
with required values?

Not that I'm aware of. Binding to Boolean and DateTime columns with AllowDBNull set to false has always worked in my experience
even when the DataGridView implies the columns from the schema of the data.
Even if it did, shouldn't using a stored
procedure get around that?

No. How the data gets into a DataTable has nothing to do with how the DataGridView handles reading and displaying the data. The
key here is to make sure the data, in memory, is what you expect. If it's not then go from there.

--
Dave Sexton

"Richard Carpenter" <ru*******@hotmail.comwrote in message news:11*********************@m73g2000cwd.googlegro ups.com...
I have a simple winform with a customers combobox, a "get orders"
button and an orders grid. Due to other requirements, I have
implemented the form to allow the user to select a customer from the
combobox and click the "get orders" button to refresh the gridview with
the selected customer's orders, via a GetDataByCustomerID stored
procedure.

The underlying Orders table includes, among others, three boolean
columns and one particular datetime column, all of which are set to NOT
NULL with default values. All of these columns have valid values
specified in the table, yet when I call the stored procedure to refresh
the grid, I get validation errors for those four columns and their data
does not display. The other columns display just fine.

As I mentioned, I'm getting this data from a stored procedure. The
stored procedure *does* return the values for those four columns. The
gridview for some reason sees those columns as having null values or
something.

I have completely deleted the form and recreated it. I have completely
deleted the dataset and recreated it. Neither had any effect. Each time
I redesigned it, the problem was present. Does the gridview have issues
with required values? Even if it did, shouldn't using a stored
procedure get around that?

I'm running out of things to try here. Any advice would be much
appreciated.

Rich
Jul 25 '06 #3
Hi Rich,
Additionally, and forgive me for the basic question, as I am still
fairly new to ADO.Net, but I have tried accessing the data in my
DataTable before and had little luck.
You are forgiven!
The object model still confounds
me to some extent. Should I drill down into the actual DataTable object
to view the data, or go through the BindingSource? If the DataTable, I
assume it starts at DataSet.DataTable...?
Here's an MSDN article that should clear up the large majority of your questions
(Pay attention in particular to the section on strong-typing DataSets if it's unfamiliar to you):

http://msdn.microsoft.com/library/de.../html/daag.asp
Also, and you can save me another thread here, when referencing that
data, how can I determine which row is current as seleted in that
DataGridView? My assumption was to look into the BindingSource object,
but I have similar questions there as with the DataTable.
Using the BindingSource is one way. dataGridView1.SelectedRows[index].DataBoundItem is another way that works regardless of the
Type of the binding source.

In VS.NET 2005 exporing your in-memory data is easy. Set a break point in code sometime you have bound the DataGridView to its data
source. Run the app in debug mode (F5) and when the application breaks into the debugger at your break point open a watch window
(Debug --Windows --Watch --Watch 1). In the watch window enter the name of your DataSet variable on one of the lines. You'll
see a magnifying glass icon under the "Value" column right after {System.Data.DataSet}. This is a DataSet "Visualizer".
Visualizers are new to VS.NET 2005. Click the icon and you'll see a Form open that displays the contents of your DataSet.

For debugging I would try to minimize the amount of data you bring down from the server so your DataSet isn't completely bloated.
Try to repro the problem with only one DataRow if possible. You shouldn't have to worry about what row is selected or visible in
the display. It will be obvious if the data in the DataGridView is the same as the data in your DataRow.

- Dave Sexton
Jul 25 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by sutphinwb | last post: by
4 posts views Thread by Mike | last post: by
6 posts views Thread by Greg | last post: by
3 posts views Thread by Jason Wilson | last post: by
8 posts views Thread by Greg Lyles | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.