Deleting rows from an unbound gridview

[Greg]

I have a gridview on my form which I have populated using a
datareader. What I would like to do is to be able to remove specified
records from the gridview, without affecting the source of the data.

I'm a bit confused about how to go about removing the rows - all the
google searches I have done so far seem to assume that the grid view
is bound and the programmer wants to delete the data from the original
source. Is there any easy way to do this - i.e. delete row x from the
grid?

I'd be grateful for any help with this!

Greg.

 

[Mark Rae]

I have a gridview on my form which I have populated using a
datareader. What I would like to do is to be able to remove specified
records from the gridview, without affecting the source of the data.

Do you mean you want to remove the rows client-side once the page has
actually been rendered, or do you want to prevent certain rows from being
rendered to the page as the data is being bound...?

 

[Greg]

Do you mean you want to remove the rows client-side once the page has
actually been rendered, or do you want to prevent certain rows from being
rendered to the page as the data is being bound...?

The latter, I suppose, but what I was hoping to do was to actually
remove the rows from the server side grid view object, not just refuse
to render those rows.

Thanks,

Greg.

 

[Mark Rae]

but what I was hoping to do was to actually remove the rows from the
server side grid view object, not just refuse to render those rows.

What's the difference...?

 

[Greg]

What's the difference...?

Visually nothing, but if I later want to refer to the server side
gridview object, I don't want to have to remember which rows have been
hidden from the the user.

Unless of course I misunderstood you.... I'm a complete beginner at
web development (I normally do win forms stuff).

Thanks.

Greg.

 

[WilsonComputing]

Greg,

As you have discovered, the GridView control does not allow you to
manipulate rows (unless you put them in the footer or something like
that). What you want to do is create the datasource (ObjectDataSource,
DataSet, etc) programatically where you can manipulate and filter its
contents. I prefer to put this logic in a separate class, but you
could put it in your code-behind class.

Then you bind the customized datasource to the gridview:
grdUsers.DataSource = myDataSource;
grdUsers.DataBind();

Best wishes,
Wesley

 

[Mark Rae]

Visually nothing, but if I later want to refer to the server side
gridview object, I don't want to have to remember which rows have been
hidden from the the user.

Aha...!

Sounds like what you want to do is fetch your underlying data into a
DataSet, create a "view" of that data which you can filter, then bind the
GridView to the filtered view instead of the underlying DataSet, which
remains intact...

using (DataSet MyDataSet = <whatever method you have for creating DataSets)
{
MyDataSet.Tables[0].DefaultView.RowFilter = "FirstName = 'Greg'";
MyGridView.DataSource = MyDataSet.Tables[0].DefaultView;
MyGridView.DataBind();
}

 

[Greg]

Visually nothing, but if I later want to refer to the server side
gridview object, I don't want to have to remember which rows have been
hidden from the the user.

Aha...!

Sounds like what you want to do is fetch your underlying data into a
DataSet, create a "view" of that data which you can filter, then bind the
GridView to the filtered view instead of the underlying DataSet, which
remains intact...

using (DataSet MyDataSet = <whatever method you have for creating DataSets)
{
MyDataSet.Tables[0].DefaultView.RowFilter = "FirstName = 'Greg'";
MyGridView.DataSource = MyDataSet.Tables[0].DefaultView;
MyGridView.DataBind();

}

Thanks a lot Wesley and Mark - I'm getting very close now to where I
need to be!

I think the best way to achieve what I want may be to create a
temporary table in the database with the user's edited copy of what
was originally extracted from the table that can't be edited. They
could then edit the contents of the temporary table to their hearts
content, and then when happy, update another table using the contents
of the temporary table. That way I don't have to worry too much about
state. Does that sound like a plan, or over complicating things?

Thanks again,

Greg.

 

[Mark Rae]

I think the best way to achieve what I want may be to create a
temporary table in the database with the user's edited copy of what
was originally extracted from the table that can't be edited. They
could then edit the contents of the temporary table to their hearts
content, and then when happy, update another table using the contents
of the temporary table. That way I don't have to worry too much about
state. Does that sound like a plan, or over complicating things?

It's a little difficult to tell as you don't mention why any of this is
necessary...

 

[Greg]

It's a little difficult to tell as you don't mention why any of this is
necessary...

Mark,

Yes, I can see why you're not too clear on what I am trying to do. The
requirements can be summarised thusNB there is a lot, lot more going
on in the form besides this, but nothing else is relevant)

There are 2 relevant tables in the database, lets call them
masterSchedule and actualSchedule.

When the user clicks on a button, a grid is shown with the contents of
the masterSchedule table. The user can then add to these details or
remove individual details. On pressing a button, the displayed
contents are inserted into the actualSchedule table. The
masterSchedule table is therefore acting as a group of suggestions, or
a template, as to what will eventually be sent to the actualSchedule
table. The masterSchedule table can never be edited by my part of the
application.

Thanks a lot for your time, and I apologise if I didn't explain fully
enough earlier on in the thread!

Greg.

 

[Mark Rae]

There are 2 relevant tables in the database, lets call them
masterSchedule and actualSchedule.
OK.

The masterSchedule table can never be edited by my part of the
application.

So what's the point of it...? E.g.

1) User fetches a dataset from masterSchedule, makes some changes, and saves
the changes into actualSchedule.

2) masterSchedule is not modified since "The masterSchedule table can never
be edited by my part of the application."

3) User fetches the same dataset from the masterSchedule - aren't they back
where they started...?

 

[Greg]

So what's the point of it...? E.g.

1) User fetches a dataset from masterSchedule, makes some changes, and saves
the changes into actualSchedule.

2) masterSchedule is not modified since "The masterSchedule table can never
be edited by my part of the application."

3) User fetches the same dataset from the masterSchedule - aren't they back
where they started...?

Absolutely 3.) is a requirement so that they can back to where they
started from at a later date. It may sound bizarre, but this is a
strict customer requirement.