RecordSet

[LabGeek]

Do I have to recreate a recordset everytime I want to use it, or can I
simply create a recordset on the form open event and access it for the
life of the form?

I guess my question is really what is the life of a recordset?

[pietlinden]

It lives as long as the containing object is open/in scope or you close
and destroy the recordset object.

[Tim Marshall]

LabGeek wrote:

I guess my question is really what is the life of a recordset?

In DAO, until you close it.

You can do what you described for a form. Just dim the recordset
variable at the form level, set it up and openrecordset at the form on
open event and have

rst.close
set rst = nothing

IN the form close event. Don't forget to deal with the database/query
object as well.

I don't have much experience with ADO, but assume the above applies as well.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Br]

LabGeek wrote:

Do I have to recreate a recordset everytime I want to use it, or can I
simply create a recordset on the form open event and access it for the
life of the form?

I guess my question is really what is the life of a recordset?

Generally the same as any any other variable's scope. If you declare a
recordset variable within a function it's scope is that function. If you
declare a global recordset variable (avoid this IMO) then the scope is as
any other global variable.

I think it is preferable to get the recordset when you need it in most
circumstances. Keeping a recordset open can create issues.

ps. declaring a recordset in the form's open event will not work as the
scope is only the open event procudure (ie. when the procedure closes so
does the recordset). Setting a global recordset variable would work but as I
said before I'd avoid that approach if possible.
--
regards,

Br@dley

[Lyle Fairfield]

Until you zap it. DAO recordsets can live on with annoying effects if
they are not explicitly released.
Today, recordsets are rarely needed. Almost all of the recordset code
we see here and in MS documents is inefficient and could be avoided,
(and should have been), with good planning, good design or knowledge of
other ways.

[BillCo]

>Today, recordsets are rarely needed. Almost all of the recordset code
we see here and in MS documents is inefficient and could be avoided,
(and should have been), with good planning, good design or knowledge of
other ways.

really? everything i know i learned from taking over maintenance of old
aps - so i guess i picked up bad habits of my predecessors, including
using recordsets to get what i need... planning, design and knowledge
of other ways... [i'm hearing this with a yoda voiceover btw] - where
can i acquire such knowledge?

[Lyle Fairfield]

Who knows?
OTTOMH and on my way out for a geocahing hike:
Read David Epson's and Roy Vidar's posts; avoid almost all the MVPs
except Terry Kreft (how could MS have made a guy so bright an MVP? must
have been a screwup at their end); Study SQL; Convince yourself that
making multiple SQL calls is as efficient as loading a recordset and
modifying data there and safer, cleaner and clearer in what you are
doing; learn some technology (such as ADO) other than DAO which is SO
restricted in its capabilities; read about JET 4 and its new
capabilities which are still ignored here in CDMA after 10? years of
existence; did I mention Study SQL? When you read someone denigrating
newer technologies ask yourself, "Is this just because he/she hasn't
mastered the new technology?" Remember that MS wants to sell its
technology to the unwashed and, perhaps, slants its answers and kb
articles to the level most likely to be accepted and used by the
unwashed.
And remember that I'm 68 and grouchy!

[BillCo]

can't someone just plug a cable into the back of my head and upload the
skillset, ala the matrix?

....no you are right... of course. having all the secrets distilled into
one potent pill is a pipe dream *sigh*. big thick books on sql, jet,
odbc, ado, api and OO VB techniques shall be studied. then i'll go into
therapy to help me come to terms it all!

Now, to find a time machine so I can dedicate years to the learning and
return to the same point in time, ala Bill and Ted.

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertherium> wrote in
news:e2**********@coranto.ucs.mun.ca:

LabGeek wrote:

I guess my question is really what is the life of a recordset?

In DAO, until you close it.

You can do what you described for a form. Just dim the recordset
variable at the form level, set it up and openrecordset at the
form on open event and have

rst.close
set rst = nothing

IN the form close event. Don't forget to deal with the
database/query object as well.

I don't have much experience with ADO, but assume the above
applies as well.

Well, in regard to scope of variables used to manipulate recordsets,
yes, the same things apply.

But ADO apparently doesn't have the problems with cleanup that DAO
does, so you don't have to manually close and clean up. If I were
using ADO, I'd do it anyway, though, just in case.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/