DataGridView creates too many new rows when inserting new data

  • Thread starter Thread starter JT
  • Start date Start date
J

JT

Hi,

I am using .NET 2.0 framework on this Winforms project. I am allowing
users to add new data to a DataGridView and subsequently updating the
database after they are through editing. My problem is that with a
repeatable sequence of clicks, the DGV will add too many new rows.
Because I'm defaulting the data in some columns, I don't allow editing
them. However, the data is not inserted in these extra rows. When I
try to delete them I get an exception. I can deal with exceptions,
but I want to figure out why it adds too many rows. Can anyone help
me determine why this is happening or where to trap it?

Because this is hard to describe or visualize, I've put a video at
http://www.Ryppl.com/Updates/ScrewedUpDataGridView.avi.

This has gotten me in other forms and it would be nice to figure it
out.

Thanks
 
If you want the contents of your server table to match the content being
displayed in your datagridview - you should use an ado.net datatable as
the datasource for your datagridview. Use an ado.net DataAdapter to
pull data from the server table into your local ado.net datatable (fill
the local table). When you perform Updtes (edits), inserts, deletes --
use the datagridview events to peform actions on the underlying
datatable. Then use the ado.Net dataAdapter to transfer these actions
to your server table. This way your server table will be synchronized
with you local datatable/datagridview.



Rich
 
quick note on updating the datagridview underlying datasource table and
the server table: you can update the underlying local table and choose
when to update the server table. You can perform
inserts/updates/deletes on the local table. Then only time the server
table will get updated is when you call dataAdapter1.Update(yourDataset,
"yourlocalTable"). You could have a button for that. In the meantime,
you can examine your local table from within the datagridview. If you
have 10 new records in the local table and have peformed updates on 15
rows in the local table and say - deleted 5 rows -- when you call
dataAdapter.update(...) that action will insert only the 10 new rows,
delete only the 5 deleted rows, and update only the rows that had been
updated locally.

If you physically/manually added one row to your local table through the
datagridview - but 3 rows got added (locally) - you should be able to
see this and then debug why this is happening.

Rich
 
quick note on updating the datagridview underlying datasource table and
the server table:  you can update the underlying local table and choose
when to update the server table.  You can perform
inserts/updates/deletes on the local table.  Then only time the server
table will get updated is when you call dataAdapter1.Update(yourDataset,
"yourlocalTable").  You could have a button for that.  In the meantime,
you can examine your local table from within the datagridview.  If you
have 10 new records in the local table and have peformed updates on 15
rows in the local table and say - deleted 5 rows -- when you call
dataAdapter.update(...) that action will insert only the 10 new rows,
delete only the 5 deleted rows, and update only the rows that had been
updated locally.

If you physically/manually added one row to your local table through the
datagridview - but 3 rows got added (locally) - you should be able to
see this and then debug why this is happening.

Rich

*** Sent via Developersdexhttp://www.developersdex.com***
Click to expand...

Because my reply to you didn't get posted on the site, I'll fill in
some details. I've determined that the DataGridView.UserAddedRow
event is getting called when this anomaly occurs. I checked the
DataGridView.RowCount and compared it to the count just prior to
making an edit. The framework (I assume) is adding 2 rows instead of
just 1. I can detect it, but removing the extra rows is very
unreliable and other bad behavior begins to happen. I have just
decided that it is too unreliable to add rows directly in the DGV
(unless I do what Rich said), but even still the user experience would
be very bad. I am able to modify rows very reliably so I have added
code and controls to add new data and am abandoning adding new rows in
the DGV. I've never tried it in .NET 3.x, but I doubt anything has
changed. Reliable is better than fancy.
 
For whatever it is worth - I have been using
VB4/VB5/VB6/VS2002/VS2003/VS2005/VS2008 very successfully since they all
came out. Each version either overcomes issues with the previous
version or adds functionality (like Linq in VS2008). It is all a matter
of how much time you are willing to invest learning how to use the
features. For good data exchange between sql server and a datagridview
you need to base the datasource of the datagridview on a local ado.net
datatable. My user's user experience is such that I am still gainfully
employed doing what I have been doing for several years. There is just
no way I could possibly achieve the same functionality with VB6 that I
have achieved with VS2005/VS2008. The addition of OOP to the .Net
versions of VB has added unbelievable amount of
horsepower/versatility/robustness to the platform. Just take the time
to learn how to use it correctly.

Rich
 
For whatever it is worth - I have been using
VB4/VB5/VB6/VS2002/VS2003/VS2005/VS2008 very successfully since they all
came out.  Each version either overcomes issues with the previous
version or adds functionality (like Linq in VS2008).  It is all a matter
of how much time you are willing to invest learning how to use the
features.  For good data exchange between sql server and a datagridview
you need to base the datasource of the datagridview on a local ado.net
datatable.  My user's user experience is such that I am still gainfully
employed doing what I have been doing for several years.  There is just
no way I could possibly achieve the same functionality with VB6 that I
have achieved with VS2005/VS2008.  The addition of OOP to the .Net
versions of VB has added unbelievable amount of
horsepower/versatility/robustness to the platform.  Just take the time
to learn how to use it correctly.

Rich

*** Sent via Developersdexhttp://www.developersdex.com***
Click to expand...

I appreciate the advice. I have been doing .NET development
since .NET 1.1 and VS 2003, through .NET 3.5 and VS 2008 (also
gainfully employed). Tying the DataGridView to a dataset through
binding, such that all modifications are immediate is too restrictive
for my application. ADO.NET is a staple and I use best practices for
my data access. I was attempting to provide some unusual
functionality to the user without compromising their desires. Mostly
I was able to accomplish that but it isn't a good time investment to
pursue that any further. Maybe I will discover that later versions
have resolved this issue.

Thanks again!
 
Back
Top