"As Database" object type in 97 Gone in XP

[RWC]

Hello,

I'm having trouble converting code in Access XP / 2002. I have some code
that declares an variable "as database" in Access 97, which is not
recognized in Access XP. I've tried to find a refrence to the items that
have changed between 97 and XP, and haven't been able to find anything yet.
I will continue looking, but if anyone can shed some light on this fairly
quickly, I would appreciate it.

Thanks In Advance!

RWC

[RWC]

Thanks John,

I had done that previously with another database as a short cut at the time,
but I would like to rely soley on the XP dlls if I can.

Thanks!
RWC

"John Rutherford" <jr************@virgin.net> wrote in message
news:1V******************@newsfep1-win.server.ntli.net...

You might have to open the 97 database in Access XP then declare database
incode as a shortcut soloution.

If not I am not sure where to find 97 vs XP differentals

"RWC" <he********@shaw.ca> wrote in message
news:FJm6b.1565$Mg7.1457@pd7tw1no...

Hello,

I'm having trouble converting code in Access XP / 2002. I have some code that declares an variable "as database" in Access 97, which is not
recognized in Access XP. I've tried to find a refrence to the items that have changed between 97 and XP, and haven't been able to find anything

yet.

I will continue looking, but if anyone can shed some light on this fairly quickly, I would appreciate it.

Thanks In Advance!

RWC

[Peter Doering]

> I'm having trouble converting code in Access XP / 2002. I have some code

that declares an variable "as database" in Access 97, which is not
recognized in Access XP. I've tried to find a refrence to the items that
have changed between 97 and XP, and haven't been able to find anything yet.
I will continue looking, but if anyone can shed some light on this fairly
quickly, I would appreciate it.

Check your references in XP (open any module, menu tools - references).
These ones you should be there:
- VBA
- MS Access 10.0
- MS DAO 3.6
- ...

Remove the check on any "not available"'s or set the correct reference.

HTH - Peter

--
No mails please.
This posting is provided AS IS with no warranties, and confers no rights.

[Allen Browne]

In Access 2002, open a code window, and choose References from the Tools
menu.

Check the box beside:
Microsoft DAO 3.6 Library.

Note that you may run into problems with Recordset objects as well. Details:
http://allenbrowne.com/ser-38.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html

"RWC" <he********@shaw.ca> wrote in message
news:UZm6b.1576$Mg7.97@pd7tw1no...

Thanks John,

I had done that previously with another database as a short cut at the time, but I would like to rely soley on the XP dlls if I can.

Thanks!
RWC

"John Rutherford" <jr************@virgin.net> wrote in message
news:1V******************@newsfep1-win.server.ntli.net...

You might have to open the 97 database in Access XP then declare database

incode as a shortcut soloution.

If not I am not sure where to find 97 vs XP differentals

"RWC" <he********@shaw.ca> wrote in message
news:FJm6b.1565$Mg7.1457@pd7tw1no...

Hello,

I'm having trouble converting code in Access XP / 2002. I have some

code that declares an variable "as database" in Access 97, which is not
recognized in Access XP. I've tried to find a refrence to the items that have changed between 97 and XP, and haven't been able to find anything

yet.

I will continue looking, but if anyone can shed some light on this fairly quickly, I would appreciate it.

Thanks In Advance!

RWC

[RWC]

Thanks Peter, But I'd like to find a solution that does not include the
older files.
"Peter Doering" <ne**@doering.org> wrote in message
news:bj************@ID-204768.news.uni-berlin.de...

I'm having trouble converting code in Access XP / 2002. I have some code that declares an variable "as database" in Access 97, which is not
recognized in Access XP. I've tried to find a refrence to the items that have changed between 97 and XP, and haven't been able to find anything yet. I will continue looking, but if anyone can shed some light on this fairly quickly, I would appreciate it.

Check your references in XP (open any module, menu tools - references).
These ones you should be there:
- VBA
- MS Access 10.0
- MS DAO 3.6
- ...

Remove the check on any "not available"'s or set the correct reference.

HTH - Peter

--
No mails please.
This posting is provided AS IS with no warranties, and confers no rights.

[Allen Browne]

You can do that if you want, but IMHO it's a great deal of unnecessary work
for a step backwards.

DAO is the native Access library. If your tables are Access tables, then DAO
is the best library to work with. In some cases it is the *only* way to set
properties. Access 2003 will again give you a reference to DAO by default,
so it is not a retrograde step to use this library.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html

"RWC" <he********@shaw.ca> wrote in message
news:Trn6b.7793$Fe6.5470@pd7tw2no...

Thanks Allen, I'd like to recode without using references to older dlls if I can.
"Allen Browne" <ab***************@bigpond.net.au> wrote in message
news:S5*******************@news-server.bigpond.net.au...

In Access 2002, open a code window, and choose References from the Tools
menu.

Check the box beside:
Microsoft DAO 3.6 Library.

Note that you may run into problems with Recordset objects as well.

Details:

http://allenbrowne.com/ser-38.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html

"RWC" <he********@shaw.ca> wrote in message
news:UZm6b.1576$Mg7.97@pd7tw1no...

Thanks John,

I had done that previously with another database as a short cut at the

time,

but I would like to rely soley on the XP dlls if I can.

Thanks!
RWC

"John Rutherford" <jr************@virgin.net> wrote in message
news:1V******************@newsfep1-win.server.ntli.net...
> You might have to open the 97 database in Access XP then declare

database

> incode as a shortcut soloution.
>
> If not I am not sure where to find 97 vs XP differentals
>
> "RWC" <he********@shaw.ca> wrote in message
> news:FJm6b.1565$Mg7.1457@pd7tw1no...
> > Hello,
> >
> > I'm having trouble converting code in Access XP / 2002. I have some code
> > that declares an variable "as database" in Access 97, which is not
> > recognized in Access XP. I've tried to find a refrence to the items that
> > have changed between 97 and XP, and haven't been able to find anything > yet.
> > I will continue looking, but if anyone can shed some light on this
fairly
> > quickly, I would appreciate it.
> >
> > Thanks In Advance!
> >
> > RWC
> >
> >
>
>

[Lyle Fairfield]

"RWC" <he********@shaw.ca> wrote in message news:<FJm6b.1565$Mg7.1457@pd7tw1no>...

I'm having trouble converting code in Access XP / 2002. I have some code
that declares an variable "as database" in Access 97, which is not
recognized in Access XP. I've tried to find a refrence to the items that
have changed between 97 and XP, and haven't been able to find anything yet.
I will continue looking, but if anyone can shed some light on this fairly
quickly, I would appreciate it.

If you post the code, it's quite likely that someone who uses ACXP
extensively will be able to suggest a simple solution. ACXP can use
ADO and CurrentProject to simplify and enhance methods that were quite
laborious in the once advanced but now archaic AC97. ADO also provides
new, powerful methods.

[Larry Linson]

"Lyle Fairfield" wrote

ACXP can use ADO and Current-
Project to simplify and enhance methods
that were quite laborious in the once
advanced but now archaic AC97. ADO
also provides new, powerful methods.

You might as well give up trying to pick a fight, Lyle. If _I_ don't want to
argue with you about this, it's unlikely that anyone does.

Have a nice day.

[Iago Gallego]

Allen,
Would you care to flesh out this statement? Are they dumping ADO?
How would that affect ADO.NET? I ask as I have apps in Acc97 which I
will need to transfer to Acc2kx soonish. They use DAO, and I would
much rather stay that way for simplicity's sake. However, I also have
a newer app in progress and it is a VB.NET beast. For that I'm using
ADO.NET. Should I prepare for DAO.NET?

Martin
"Allen Browne" <ab***************@bigpond.net.au> wrote in message news:<4F*******************@news-server.bigpond.net.au>...

You can do that if you want, but IMHO it's a great deal of unnecessary work
for a step backwards.

DAO is the native Access library. If your tables are Access tables, then DAO
is the best library to work with. In some cases it is the *only* way to set
properties. Access 2003 will again give you a reference to DAO by default,
so it is not a retrograde step to use this library.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
"RWC" <he********@shaw.ca> wrote in message
news:Trn6b.7793$Fe6.5470@pd7tw2no...

Thanks Allen, I'd like to recode without using references to older dlls if

I

can.
"Allen Browne" <ab***************@bigpond.net.au> wrote in message
news:S5*******************@news-server.bigpond.net.au...

In Access 2002, open a code window, and choose References from the Tools
menu.

Check the box beside:
Microsoft DAO 3.6 Library.

Note that you may run into problems with Recordset objects as well. Details: http://allenbrowne.com/ser-38.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html

[Lyle Fairfield]

Ma***************@dsto.defence.gov.au (Iago Gallego) wrote in
news:a5**************************@posting.google.c om:

Allen,
Would you care to flesh out this statement? Are they dumping ADO?
How would that affect ADO.NET? I ask as I have apps in Acc97 which I
will need to transfer to Acc2kx soonish. They use DAO, and I would
much rather stay that way for simplicity's sake. However, I also have
a newer app in progress and it is a VB.NET beast. For that I'm using
ADO.NET. Should I prepare for DAO.NET?

DAO.Net is actually "DOA"!

--
Lyle

[David W. Fenton]

ab***************@bigpond.net.au (Allen Browne) wrote in
<Ma*******************@news-server.bigpond.net.au>:

DAO is the native library that was designed for Access, and
generally exposes the functionaly within Access/JET best and most
efficiently. If the final release of Access 2003 contains the
reference to the DAO library (as the beta did), it will simplify
the task of conversion to the new version. . . .
Is it not the case that *conversion* from A97 to A2K/A2K2 retains
the reference to DAO? It is only when you create a fresh A2K/A2K2
database and import the objects from the A97 database that you
don't automatically get the DAO reference.

I wouldn't exactly call that "converting," which is why I've always
been puzzled why so many people encounter the error -- instead of
using the built-in conversion functionality, they create a new MDB
and then run into the problem.

[]
With JET tables, I use ADO/ADOX only for the new features, such as
Decimal fields and cascade-to-null relations. MS has not updated
DAO to include this functionality.

Is this a feature of Jet 4? I didn't realize it was there. It's a
useful one, especially for those cases where a foreign key can be
Null or limited to a PK from another table (CompanyID for a
person's employer, for example).

But other than the User Roster, is there anything that ADO offers
with Jet that DAO does not that is outside the scope of table
creation/restructuring (i.e., decimal type and cascade to Null are
both useful only at the time you are designing a schema)? Put
another way, other than User Roster, what reason would there be to
use ADO in a Jet application, as opposed to during development?

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

[Allen Browne]

Embedded.

"David W. Fenton" <dX********@bway.net> wrote in message
news:93*********************@24.168.128.90...

ab***************@bigpond.net.au (Allen Browne) wrote in
<Ma*******************@news-server.bigpond.net.au>:

DAO is the native library that was designed for Access, and
generally exposes the functionaly within Access/JET best and most
efficiently. If the final release of Access 2003 contains the
reference to the DAO library (as the beta did), it will simplify
the task of conversion to the new version. . . .
Is it not the case that *conversion* from A97 to A2K/A2K2 retains
the reference to DAO? It is only when you create a fresh A2K/A2K2
database and import the objects from the A97 database that you
don't automatically get the DAO reference.

I wouldn't exactly call that "converting," which is why I've always
been puzzled why so many people encounter the error -- instead of
using the built-in conversion functionality, they create a new MDB
and then run into the problem.

Yes, the actual process of conversion to A2000 or A2002 retains the DAO
reference (or more specifically replaces DAO 3.5x with the DAO 3.6 library
references). I'm not sure whether people prefer to import: I certainly do,
because I won't let an A2000 or later database anywhere near an object until
I have disabled the "Name AutoCorrect" option.

Where the real problem comes is when users try to copy code - from one of
our books or websites. After posting this last night, I took note, and
answered 3 questions in the n.g.s relating to references.

With JET tables, I use ADO/ADOX only for the new features, such as
Decimal fields and cascade-to-null relations. MS has not updated
DAO to include this functionality.

Is this a feature of Jet 4? I didn't realize it was there. It's a
useful one, especially for those cases where a foreign key can be
Null or limited to a PK from another table (CompanyID for a
person's employer, for example).

Yes, JET 4 supports cascade-to-null. It sounds like it could be useful, but
I have not yet used it in a production database. 90% of foreign keys should
be marked "Required" of course. For the remaining 10%, it represents a loss
of data, and when I'm developing I tend to think in terms of minimizing and
respecting the time of the data entry operators, so I find it tough to just
allow their hard work to go down the tubes. :-)

There have been times when I have nullified a field in a transaction, so I
will probably use it one day, but IME it's not as useful as it sounds like
it could be.
But other than the User Roster, is there anything that ADO offers
with Jet that DAO does not that is outside the scope of table
creation/restructuring (i.e., decimal type and cascade to Null are
both useful only at the time you are designing a schema)? Put
another way, other than User Roster, what reason would there be to
use ADO in a Jet application, as opposed to during development?

Again, I haven't found much ADO stuff that I consider really useful. The
Decimal field type is also something I haven't used in production. It's
inefficient (96-bit), incompletely implemented (no matching type in VBA, so
you can't define a constant of this type), and best reserved for cases where
the scaling beyond 4 places (Currency) is absolutely essential.

So, for applications where Access is both the front end and the back end,
DAO is the native library, and we know its limiations, bugs, and
workarounds. I consider that experience we have built up and shared together
via these newsgroups to be a significant reason not to move away from DAO.