Re: Effects on RST in Calling Proc

Tim Marshall <TIMMY!@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
news:dfmjk7$qk4$1@xxxxxxxxxxxxxxxxxx:

> David W. Fenton wrote:
>
>> Obviously, the snapshot avoids that, but I think it's better to
>> code the original procedure in a way that is likely to survive
>> the largest number of revisions without needing to be altered,
>> and to me, storing the PK value has that advantage over either
>> alternative that is dependent on the state of the recordset,
>> rather than derived from the underlying data.
>
> Thanks for the feedback.
>
> In the original proc, the recordset is snapshot and is passed to
> the called proc so that another field can be searched for a value
> that is being tested in the calling proc. So the nature of the
> two together is such that the recordset will not be changed.

If your code or the context in which it is used never changes, then
it's not an issue. I prefer writing code that will survive
foreseeable changes, even ones that are mistaken.

> I think you're right, the PK find first alternative is probably
> better, though. But as I said, the nature of my procedures in
> this case are such that changes made to the recordset in the
> second procedure would not be appropriate. I suppose the two
> could have been melded into one procedure, but I thought the
> second could lend itself later in development to other procs
> similar to the one here that calls it.

My point is not about the code in its current state, but about what
might happen in the future when you or another coder has forgotten
the original imitations on what you can do to the code. By using PK
navigation, you avoid the issue entirely.

> I try as much as possible to avoid data manipulation by row
> processing and prefer set processing, ie, I prefer to execute an
> update or insert statement as opposed to going through each row in
> a recordset and doing edit/update, so I generally stick with
> dbopensnapshot.

But there are operations that need to be performed that *can't* be
done with set processing, so one sometimes does need to edit an
actual recordset.

I have never used snapshots because my impression was that they were
much sloer than dynasets. I do know that at one point I got religion
and tried using them all over the place and the app slowed to a
crawl, so I switched back to the default recordset type, dynasets.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
.

Relevant Pages

  • Re: how to retrieve [RecordsAffected] count from cmd.Excecute in V
    ... the original j a variant was because Longs and Integers by default are 0. ... And here is the related ADO code to invoke the Proc and get the "Records ... assigning the result to a Recordset object) try removing the SELECT ...
    (microsoft.public.data.ado)
  • How to get past an error?
    ... sql error but still need to return a recordset or print statement that ... statemets and depending on the type of error, might see the recordset.. ... in batchs.. ... PS try to make this proc send back the error,print and get the record ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Determining column names and types of recordset returned by stored procedure
    ... then wraps the call to the proc with SET NO_BROWSETABLE and SET FMTONLY ... the code above actually returns one empty recordset for each ... Visual Studio would only show TextResults as a resulting ... >> Studio 2003 Server explorer is reliably providing the information ...
    (microsoft.public.sqlserver.programming)
  • Re: Zugriff auf Access-Datenbank über ODBC
    ... Requery ist genau die Funktion, ... Auszug aus der Doku: ... If the recordset is a snapshot, you must call Requery to reflect edits by ...
    (microsoft.public.de.vc)
  • Re: Effects on RST in Calling Proc
    ... the original procedure in a way that is likely to survive the ... In the original proc, the recordset is snapshot and is passed to the called proc so that another field can be searched for a value that is being tested in the calling proc. ... I try as much as possible to avoid data manipulation by row processing and prefer set processing, ie, I prefer to execute an update or insert statement as opposed to going through each row in a recordset and doing ...
    (comp.databases.ms-access)