When is "db.close" needed?

[Lauren Wilson]

A2K app:

Question: is the flagged line (<<<) below necessary. If that line is
needed, what effect does it have (if any) on the fact that the very
same database is the linked back end db?

Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")
Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

If rst!GroupVersion = "G1VER" Then
IsRMTGver = True
Else
IsRMTGver = False
End If

rst.Close
Set rst = Nothing
db.Close <<< is this line necessary?
Set db = Nothing

[Lauren Wilson]

Really scratching my head on this one folks. Any advice will be much
appreciated.
I ask about this because I SUSPECT that the following error is somehow
involved with the fact that as part of my app startup routine, I open
and close the back-end database several times to retrieve various
public variables from the configuration tables. To cure that
suspected problem, I re-grouped my variables into a single
"opendatabase" session. That had zero effect on the problem.

This only RECENTLY started happening to our 5 year old application
that has been solid as a rock until after some recent updates. When
the error below happens, the ONLY way to escape is to terminate the
process using the Task Manager.

---------------------------
Form_frmApp_Title.cmdExit_Click
---------------------------
Error 2501: The Close action was canceled.
---------------------------
OK
---------------------------

There is NO code ANYWHERE that cancels the close action for the title
screen form.

On Thu, 07 Apr 2005 00:08:12 -0500, Lauren Wilson
<pr*****@private.com> wrote:

A2K app:

Question: is the flagged line (<<<) below necessary. If that line is
needed, what effect does it have (if any) on the fact that the very
same database is the linked back end db?

Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")
Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

If rst!GroupVersion = "G1VER" Then
IsRMTGver = True
Else
IsRMTGver = False
End If

rst.Close
Set rst = Nothing
db.Close <<< is this line necessary?
Set db = Nothing

[Steve Jorgensen]

On Thu, 07 Apr 2005 00:08:12 -0500, Lauren Wilson <pr*****@private.com> wrote:

A2K app:

Question: is the flagged line (<<<) below necessary. If that line is
needed, what effect does it have (if any) on the fact that the very
same database is the linked back end db?

Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")
Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

If rst!GroupVersion = "G1VER" Then
IsRMTGver = True
Else
IsRMTGver = False
End If

rst.Close
Set rst = Nothing
db.Close <<< is this line necessary?
Set db = Nothing

When using DAO objects, resources are not always released properly unless DAO
objects are closed, then released in reverse dependency order. It may be that
there are certain steps of that which could be safely omitted in all cases,
but none of us is sure what they are, nor could we remember if we did. It's
safest, then, to always do all the tear-down steps.

Be careful, though, and don't close objects in code that does not explicitly
open them. Do not, for instance, close a database reference retrieved by
calling CurrentDB. If you opened it, close it. If you didn't open it, don't
close it.

[Bruno Campanini]

"Lauren Wilson" <pr*****@private.com> wrote in message
news:pn********************************@4ax.com...

rst.Close
Set rst = Nothing
db.Close <<< is this line necessary?
Set db = Nothing

I'm using Access since v1.00 (1992).

Rarely used rst.Close:
Set rst=CurrentDb.OpenRecordset(xxxxx)
rst.Close
Set rst=CurrentDb.OpenRecordset(yyyyy)

Never used:
Set rst = Nothing
db.Close
Set db = Nothing

I think they are a sort of redundancy many programmers
use. As it is Me.
Or I never met the the circumstance that requires them.

Bruno

[paii, Ron]

"Lauren Wilson" <pr*****@private.com> wrote in message
news:1b********************************@4ax.com...

Really scratching my head on this one folks. Any advice will be much
appreciated.
I ask about this because I SUSPECT that the following error is somehow
involved with the fact that as part of my app startup routine, I open
and close the back-end database several times to retrieve various
public variables from the configuration tables. To cure that
suspected problem, I re-grouped my variables into a single
"opendatabase" session. That had zero effect on the problem.

This only RECENTLY started happening to our 5 year old application
that has been solid as a rock until after some recent updates. When
the error below happens, the ONLY way to escape is to terminate the
process using the Task Manager.

---------------------------
Form_frmApp_Title.cmdExit_Click
---------------------------
Error 2501: The Close action was canceled.
---------------------------
OK
---------------------------

There is NO code ANYWHERE that cancels the close action for the title
screen form.

On Thu, 07 Apr 2005 00:08:12 -0500, Lauren Wilson
<pr*****@private.com> wrote:

A2K app:

Question: is the flagged line (<<<) below necessary. If that line is
needed, what effect does it have (if any) on the fact that the very
same database is the linked back end db?

Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")
Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

If rst!GroupVersion = "G1VER" Then
IsRMTGver = True
Else
IsRMTGver = False
End If

rst.Close
Set rst = Nothing
db.Close <<< is this line necessary?
Set db = Nothing

I have seen this when opening and closing a Database that Access already has
open.

If you are opening an attached table you can replace

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")

with

Set db = Currentdb

You won't need to close it because you did not open it.
In some cases you could replace

Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

with

Set rst = CurrentDB.OpenRecordset("tblStoredUserChoices", dbOpenTable)

eliminating the "db" variable

[Steve Jorgensen]

On Thu, 07 Apr 2005 12:11:17 GMT, "Bruno Campanini" <br*************@tin.it>
wrote:

"Lauren Wilson" <pr*****@private.com> wrote in message
news:pn********************************@4ax.com.. .

rst.Close
Set rst = Nothing
db.Close <<< is this line necessary?
Set db = Nothing

I'm using Access since v1.00 (1992).

Rarely used rst.Close:
Set rst=CurrentDb.OpenRecordset(xxxxx)
rst.Close
Set rst=CurrentDb.OpenRecordset(yyyyy)

Never used:
Set rst = Nothing
db.Close
Set db = Nothing

I think they are a sort of redundancy many programmers
use. As it is Me.
Or I never met the the circumstance that requires them.

Bruno

Then you have neve used your program long enough to have resource problems. I
have fixed many problems with applications by auditing the code and making
sure DAO objects were explicitly cleaned up in the right order.

[Lauren Wilson]

Thanks Ron. This was very helpful!
On Thu, 7 Apr 2005 07:42:43 -0500, "paii, Ron" <pa**@packairinc.com>
wrote:

"Lauren Wilson" <pr*****@private.com> wrote in message
news:1b********************************@4ax.com.. .

Really scratching my head on this one folks. Any advice will be much
appreciated.
I ask about this because I SUSPECT that the following error is somehow
involved with the fact that as part of my app startup routine, I open
and close the back-end database several times to retrieve various
public variables from the configuration tables. To cure that
suspected problem, I re-grouped my variables into a single
"opendatabase" session. That had zero effect on the problem.

This only RECENTLY started happening to our 5 year old application
that has been solid as a rock until after some recent updates. When
the error below happens, the ONLY way to escape is to terminate the
process using the Task Manager.

---------------------------
Form_frmApp_Title.cmdExit_Click
---------------------------
Error 2501: The Close action was canceled.
---------------------------
OK
---------------------------

There is NO code ANYWHERE that cancels the close action for the title
screen form.

On Thu, 07 Apr 2005 00:08:12 -0500, Lauren Wilson
<pr*****@private.com> wrote:

>
>A2K app:
>
>Question: is the flagged line (<<<) below necessary. If that line is
>needed, what effect does it have (if any) on the fact that the very
>same database is the linked back end db?
>
>
>
> Dim db As DAO.Database
> Dim rst As DAO.Recordset
>
> Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")
> Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)
>
> If rst!GroupVersion = "G1VER" Then
> IsRMTGver = True
> Else
> IsRMTGver = False
> End If
>
> rst.Close
> Set rst = Nothing
> db.Close <<< is this line necessary?
> Set db = Nothing

I have seen this when opening and closing a Database that Access already has
open.

If you are opening an attached table you can replace

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")

with

Set db = Currentdb

You won't need to close it because you did not open it.
In some cases you could replace

Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

with

Set rst = CurrentDB.OpenRecordset("tblStoredUserChoices", dbOpenTable)

eliminating the "db" variable

[jimfortune]

paii, Ron wrote:

In some cases you could replace

Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

with

Set rst = CurrentDB.OpenRecordset("tblStoredUserChoices", dbOpenTable)
eliminating the "db" variable

To quote Han Solo -- "I've got a bad feeling about this." I vaguely
recall that there is a potential problem that was discussed in this NG
when setting a recordset with CurrentDB directly that goes away when
the db variable is used. I also agree with Steve about carefully
closing anything that you open and only closing what you have already
opened.

James A. Fortune

[David W. Fenton]

"Bruno Campanini" <br*************@tin.it> wrote in
news:Fr***********************@news4.tin.it:

"Lauren Wilson" <pr*****@private.com> wrote in message
news:pn********************************@4ax.com...

rst.Close
Set rst = Nothing
db.Close <<< is this line necessary?
Set db = Nothing

I'm using Access since v1.00 (1992).

Rarely used rst.Close:
Set rst=CurrentDb.OpenRecordset(xxxxx)
rst.Close
Set rst=CurrentDb.OpenRecordset(yyyyy)

Never used:
Set rst = Nothing
db.Close
Set db = Nothing

I think they are a sort of redundancy many programmers
use. As it is Me.
Or I never met the the circumstance that requires them.

No, it's not a redundancy.

You *can't* close the db returned as a reference by CurrentDB(),
because it's the MDB that's currently open in the Access UI. You
can't close it in code with .Close.

But if you open some *other* db, you really do need to close it.

In the current instance, the programmer is opening the back end
database, so that can't possibly be the MDB open in the Access UI,
so she definitely does need to close it.

And even if you don't close the db, you need to set its variable to
Nothing in order to insure that all resources are released. Failure
to do so can result in the "Access won't close" error, among other
problems.

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

[David W. Fenton]

Lauren Wilson <pr*****@private.com> wrote in
news:pn********************************@4ax.com:

A2K app:

Question: is the flagged line (<<<) below necessary. If that
line is needed, what effect does it have (if any) on the fact that
the very same database is the linked back end db?

Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")

I'm assuming that "C:\AppDir\" is a typo for a real MDB filename.

In any case, why are you using "Workspaces(0)"?

DBEngine.OpenDatabase() is all I've ever used.

Someone later suggested using CurrentDB(), but that only works for
you if you have table links in your front end. And if you have that,
why are you bothering with OpenDatabase?

Secondly, some folks prefer DBEngine(0)(0) over CurrentDB(), but I
have a problem with it, as under certain circumstances, it will
return a reference to a wizard MDE instead of to the MDB you *think*
you're working in. It is certainly faster, though, as it doesn't
refresh collections.

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

[Steve Jorgensen]

On Thu, 07 Apr 2005 20:33:20 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Lauren Wilson <pr*****@private.com> wrote in
news:pn********************************@4ax.com :

A2K app:

Question: is the flagged line (<<<) below necessary. If that
line is needed, what effect does it have (if any) on the fact that
the very same database is the linked back end db?

Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")

I'm assuming that "C:\AppDir\" is a typo for a real MDB filename.

In any case, why are you using "Workspaces(0)"?

All the examples I've ever seen use Workspaces(0). I didn't know you could
use DBEngine.OpenDatabase. I guess the first workspace in the colleciton is
the default?

[paii, Ron]

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:k1********************************@4ax.com...

On Thu, 07 Apr 2005 20:33:20 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Lauren Wilson <pr*****@private.com> wrote in
news:pn********************************@4ax.com :

A2K app:

Question: is the flagged line (<<<) below necessary. If that
line is needed, what effect does it have (if any) on the fact that
the very same database is the linked back end db?

Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")
I'm assuming that "C:\AppDir\" is a typo for a real MDB filename.

In any case, why are you using "Workspaces(0)"?

All the examples I've ever seen use Workspaces(0). I didn't know you

could use DBEngine.OpenDatabase. I guess the first workspace in the colleciton is the default?

Back when I started with Access 2, the examples in the manuals showed
Workspaces(0).

[Lauren Wilson]

On Thu, 07 Apr 2005 11:10:48 -0500, Lauren Wilson
<pr*****@private.com> wrote:

Thanks Ron. This was very helpful!
On Thu, 7 Apr 2005 07:42:43 -0500, "paii, Ron" <pa**@packairinc.com>
wrote:

"Lauren Wilson" <pr*****@private.com> wrote in message
news:1b********************************@4ax.com. ..

Really scratching my head on this one folks. Any advice will be much
appreciated.
I ask about this because I SUSPECT that the following error is somehow
involved with the fact that as part of my app startup routine, I open
and close the back-end database several times to retrieve various
public variables from the configuration tables. To cure that
suspected problem, I re-grouped my variables into a single
"opendatabase" session. That had zero effect on the problem.

This only RECENTLY started happening to our 5 year old application
that has been solid as a rock until after some recent updates. When
the error below happens, the ONLY way to escape is to terminate the
process using the Task Manager.

---------------------------
Form_frmApp_Title.cmdExit_Click
---------------------------
Error 2501: The Close action was canceled.
---------------------------
OK
---------------------------

There is NO code ANYWHERE that cancels the close action for the title
screen form.

On Thu, 07 Apr 2005 00:08:12 -0500, Lauren Wilson
<pr*****@private.com> wrote:

>
>A2K app:
>
>Question: is the flagged line (<<<) below necessary. If that line is
>needed, what effect does it have (if any) on the fact that the very
>same database is the linked back end db?
>
>
>
> Dim db As DAO.Database
> Dim rst As DAO.Recordset
>
> Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")
> Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)
>
> If rst!GroupVersion = "G1VER" Then
> IsRMTGver = True
> Else
> IsRMTGver = False
> End If
>
> rst.Close
> Set rst = Nothing
> db.Close <<< is this line necessary?
> Set db = Nothing

I have seen this when opening and closing a Database that Access already has
open.

If you are opening an attached table you can replace

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")

with

Set db = Currentdb

You won't need to close it because you did not open it.
In some cases you could replace

Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

with

Set rst = CurrentDB.OpenRecordset("tblStoredUserChoices", dbOpenTable)

eliminating the "db" variable

Well I have now tested this. Access reminded me that using:

Set rst = CurrentDB.OpenRecordset("tblStoredUserChoices", dbOpenTable)

in place of:

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\App _BE.MDB")
Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

causes an error when the target table is in a linked back end
database. It produces an error: "Invalid operation"

Back to square one.

[Tim Marshall]

Lauren Wilson wrote:

Well I have now tested this. Access reminded me that using:

Set rst = CurrentDB.OpenRecordset("tblStoredUserChoices", dbOpenTable)

in place of:

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\App _BE.MDB")
Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

causes an error when the target table is in a linked back end
database. It produces an error: "Invalid operation"

Back to square one.

Then remove the dbopentable type - if you leave it out, the default for
a linked table, for DAO, is a dynaset. I will usually use
dbOpensnapshot anyway - makes for a much faster load, especially when
the source is against a very large table. If I later change the values
in the source (in your case, the source is "tblStoredUserChoices"), and
this is a persistent recordset (I'm using "persistent" to describe a
recordset I open at the beginning of a asession with an app so that the
link to the linked BE is kept open and this really shortens retrieval
time for records from BE tables).
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tim Marshall]

Tim Marshall wrote:

Then remove the dbopentable type - if you leave it out, the default for
a linked table, for DAO, is a dynaset. I will usually use
dbOpensnapshot anyway - makes for a much faster load, especially when
the source is against a very large table. If I later change the values
in the source (in your case, the source is "tblStoredUserChoices"), and
this is a persistent recordset (I'm using "persistent" to describe a
recordset I open at the beginning of a asession with an app so that the
link to the linked BE is kept open and this really shortens retrieval
time for records from BE tables).

Oops, didn't finish my thought:

If I later change the values in the source (in your case, the source is
"tblStoredUserChoices"), and this is a persistent recordset (I'm using
"persistent" to describe a recordset I open at the beginning of a
asession with an app so that the link to the linked BE is kept open and
this really shortens retrieval time for records from BE tables), as part
of the procedure for running the update, I simply close the persistent
recordset and then reopen it.

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

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:k1********************************@4ax.com:

On Thu, 07 Apr 2005 20:33:20 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Lauren Wilson <pr*****@private.com> wrote in
news:pn********************************@4ax.co m:

A2K app:

Question: is the flagged line (<<<) below necessary. If that
line is needed, what effect does it have (if any) on the fact
that the very same database is the linked back end db?

Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")

I'm assuming that "C:\AppDir\" is a typo for a real MDB filename.

In any case, why are you using "Workspaces(0)"?

All the examples I've ever seen use Workspaces(0). I didn't know
you could use DBEngine.OpenDatabase. I guess the first workspace
in the colleciton is the default?

Nope. OpenDatabase is a member of both DBEngine and Workspaces. Look
it up in the browser.

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

[David W. Fenton]

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

Lauren Wilson wrote:

Well I have now tested this. Access reminded me that using:

Set rst = CurrentDB.OpenRecordset("tblStoredUserChoices",
dbOpenTable)

in place of:

Set db =
DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\App _BE.MDB") Set
rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

causes an error when the target table is in a linked back end
database. It produces an error: "Invalid operation"

Back to square one.

Then remove the dbopentable type - if you leave it out, the
default for a linked table, for DAO, is a dynaset. I will usually
use dbOpensnapshot anyway - makes for a much faster load,
especially when the source is against a very large table. If I
later change the values in the source (in your case, the source is
"tblStoredUserChoices"), and this is a persistent recordset (I'm
using "persistent" to describe a recordset I open at the beginning
of a asession with an app so that the link to the linked BE is
kept open and this really shortens retrieval time for records from
BE tables).

The only reason to open as a table-type recordset is to use SEEK,
right?

If a table called "tblStoredUserChoices" has enough records to
benefit from the use of SEEK over .FindFirst, then I'd say you're
getting a lot more out of Jet than I'd ever image was possible
(i.e., you have 10s of thousands of users).

I simply can't conceive of a circumstance where a plain
non-table-type recordset (dynaset) opened with a WHERE clause
limited to the current user would not be faster than any kind of
navigation of a table-type recordset using SEEK.

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

[Lauren Wilson]

On Fri, 08 Apr 2005 16:22:24 -0230, Tim Marshall
<TI****@PurplePandaChasers.Moertherium> wrote:

Lauren Wilson wrote:

Well I have now tested this. Access reminded me that using:

Set rst = CurrentDB.OpenRecordset("tblStoredUserChoices", dbOpenTable)

in place of:

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\App _BE.MDB")
Set rst = db.OpenRecordset("tblStoredUserChoices", dbOpenTable)

causes an error when the target table is in a linked back end
database. It produces an error: "Invalid operation"

Back to square one.

Then remove the dbopentable type - if you leave it out, the default for
a linked table, for DAO, is a dynaset. I will usually use
dbOpensnapshot anyway - makes for a much faster load, especially when
the source is against a very large table. If I later change the values
in the source (in your case, the source is "tblStoredUserChoices"), and
this is a persistent recordset (I'm using "persistent" to describe a
recordset I open at the beginning of a asession with an app so that the
link to the linked BE is kept open and this really shortens retrieval
time for records from BE tables).

WOW! Thanks Tim!

Using THIS line:

Set rst = CurrentDb.OpenRecordset("tblStoredUserChoices",
dbOpenSnapshot)

allowed me to eliminate this line:
Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\App _BE.MDB")

[Tim Marshall]

David W. Fenton wrote:

I simply can't conceive of a circumstance where a plain
non-table-type recordset (dynaset) opened with a WHERE clause
limited to the current user would not be faster than any kind of
navigation of a table-type recordset using SEEK.

Quite right, I didn't catch that. The OP should put an SQL statement
instead of the table name. By the sound of the name, I would assume the
tblStoredUserChoices has records for individual users.

SO, a better idea might be:

dim strSql as string

'rst and db are dimmed as globals, if this is a recordset you want open
for the whole mdb/mde session

set db = access.currentdb

strSql = "Select * from tblStoredUserChoices where User_Name = """ &
whatever & """"

set rst = db.openrecordset(strsql, dbopensnapshot)

I think this would be a better solution, David? You're right, it's kind
of nuts opening a whole table, especially if there are lots of records...

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Steve Jorgensen]

On Fri, 08 Apr 2005 19:08:29 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:k1********************************@4ax.com :

On Thu, 07 Apr 2005 20:33:20 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Lauren Wilson <pr*****@private.com> wrote in
news:pn********************************@4ax.com :

A2K app:

Question: is the flagged line (<<<) below necessary. If that
line is needed, what effect does it have (if any) on the fact
that the very same database is the linked back end db?

Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine.Workspaces(0).OpenDatabase("C:\AppDir\")

I'm assuming that "C:\AppDir\" is a typo for a real MDB filename.

In any case, why are you using "Workspaces(0)"?

All the examples I've ever seen use Workspaces(0). I didn't know
you could use DBEngine.OpenDatabase. I guess the first workspace
in the colleciton is the default?

Nope. OpenDatabase is a member of both DBEngine and Workspaces. Look
it up in the browser.

How is that different than what I said? If you open a database, it has to be
in some workspace, so opening it from DBEngine, must default to some workspace
to use.