Really disconnect a recordset?
- From: "Mike Jansen" <mjansen_nntp@xxxxxxxx>
- Date: Mon, 22 Aug 2005 16:13:29 -0400
Is there a way to completely disconnect a recordset so that it has no memory
of its server origins? So that things like
rs.Field(0).Properties("BASETABLENAME") will be blank? So it doesn't know
it was created via OLE DB for SQL Server? So that it won't validate that
"hey you really can't update that on the server"?
I've got a recordset that comes from a query where some of the fields are
derived and not actual table fields. On the client side, I want to be able
to update those fields in the local recordset without ever doing an update
back to SQL Server. Because of the underlying schema and dynamic
properties, ADO is not allowing me to "update" the these fields.
Basically, I want to take the data from this recordset and put it into
another recordset with an identical "shallow" schema -- meaning same column
names and column types but none of the other attributes that link it to the
provider, so that I can manipulate it like a local-only recordset?
Do I basically need to create a new recordset by looping through the old
one's field defs and then copy the rows one by one?
Any other solutions would be greatly appreciated.
Thanks,
Mike
.
- Follow-Ups:
- Re: Really disconnect a recordset?
- From: Stephen Howe
- Re: Really disconnect a recordset?
- Prev by Date: Re: Trapping CommitTrans - returns success even when failed!
- Next by Date: Re: ADO 2.7: Multiple-step operation generated errors
- Previous by thread: ADO 2.7: Multiple-step operation generated errors
- Next by thread: Re: Really disconnect a recordset?
- Index(es):
Relevant Pages
|
|