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.

"Greg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

>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...?

On 1 Feb, 19:19, "Mark Rae" <m...@markNOSPAMrae.com> wrote:
> "Greg" <spammesil...@yahoo.co.uk> wrote in message
>
> news:(E-Mail Removed)...
>
> >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...?

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.

"Greg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 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...?

On 1 Feb, 19:34, "Mark Rae" <m...@markNOSPAMrae.com> wrote:
> "Greg" <spammesil...@yahoo.co.uk> wrote in message
>
> news:(E-Mail Removed)...
>
> > 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...?

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.

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

>
> > > 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...?
>
> 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.

"Greg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 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();
}

On 1 Feb, 20:26, "Mark Rae" <m...@markNOSPAMrae.com> wrote:
> "Greg" <spammesil...@yahoo.co.uk> wrote in message
>
> news:(E-Mail Removed)...
>
> > 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.

"Greg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 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...

On 2 Feb, 11:20, "Mark Rae" <m...@markNOSPAMrae.com> wrote:
> "Greg" <spammesil...@yahoo.co.uk> wrote in message
>
> news:(E-Mail Removed)...
>
> > 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...

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.