Office 12 Access Database Engine conflicts with DAO 3.6 library

[merwcat]

Hi converting a large secured, networked Access 2003 database that has
already successfully converted to an mdb in Access 2007, to the new accb file
format. By default the MS DAO 3.6 library did not install and when I try to
install it it refuses to install because it conflicts with the MS Office 12
Access Database Engine Library. Without DAO 3.6 large parts of my code fail
to compile as I have always used DAO in preference to ADO. The database
compiles no problem if I remove the MS Office 12 Access Database Engine
library. What are the problems I am likely to face if I leave this library
out. I really dont want to convert all the DAO to ADO as its a large mission
critical database, although it is an option. The reason for the second
conversion is I am trying to future proof it before I retire and the use of
an SQL server for some of the database tables is envisaged as an option in
the future as we already have spare licences for it.

 

[Douglas J. Steele]

If you've got the reference to MS Office 12 Access Database Engine Library,
then all of your DAO code should work fine. ADE is the replacement for DAO.
You must have it, and not DAO, when working with accdb files.

 

[dch3]

If its a mission-critical application, go ahead and upsize to SQLServer. I
personally don't trust Access security any further than I through the
building that I work in. Not only is SQLServer much more robust, you can
build triggers that automatically create an audit log that captures changes
to records so that if someone should happen to start maliciously tampering
you can trace it and possibly restore the records to their pre-tampering
values. When Access, if you can get to the data you can do any thing and
there's nothing stopping you.

 

[David W. Fenton]

By default the MS DAO 3.6 library did not install and when I try
to install it it refuses to install because it conflicts with the
MS Office 12 Access Database Engine Library. Without DAO 3.6
large parts of my code fail to compile as I have always used DAO
in preference to ADO.

The MS Office 12 ADE library is really DAO [next version], and it is
fully backwardly compatible with DAO 3.6. You can't have both, and
you can't use 3.6. You should use only the ADE reference. If it
doesn't compile, then perhaps you have a problematic installation of
A2K7, where the ADO library is not properly registered.

 

[David W. Fenton]

If its a mission-critical application, go ahead and upsize to
SQLServer.

This is bullshit advice for the question asked.

 

[merwcat]

Hi thanks for the replies, I now know at least I have to get it compiled with
the latest library if I intend to use accb.
1. The problem does not relate to a defective install of 2007. I have tested
that on my own systems.
2. I have a good reason for not wanting to go straight into a full
conversion to SQL - one of the reasons Access has worked for us for ten years
is being able to make fast changes as our systems develop with no reference
to outside agencies. Its part used as a security tool that checks other
departments full size server databases for data errors and part used to
retain our own in house data. Hoping to use SQL server in future to secure
small video files we now open in Access from the file system and securing a
few but not all Access tables but still retain Access as a fully functional
front end.
3. From the replies it points me at the fact that the database may not have
converted correctly from 2003 to 2007 using the convert option, possibly due
to the fact it was a secured database with a lot of customization. I did
wonder because I expected to lose the Add In ribbon with my old menus when I
converted and I can still open them in the accb. I will try opening a new
blank accb database and import the converted objects to see what happens next.
It is maybe overkill because the original mdb after a bit of work on filters
operates OK in 2007. I am just trying to think ahead so they dont get caught
out with an obscelescent file system they cannnot upgrade if I ever retire.
Again thanks for the replies and has anybody else come accross this problem.

By default the MS DAO 3.6 library did not install and when I try
to install it it refuses to install because it conflicts with the
MS Office 12 Access Database Engine Library. Without DAO 3.6
large parts of my code fail to compile as I have always used DAO
in preference to ADO.

The MS Office 12 ADE library is really DAO [next version], and it is
fully backwardly compatible with DAO 3.6. You can't have both, and
you can't use 3.6. You should use only the ADE reference. If it
doesn't compile, then perhaps you have a problematic installation of
A2K7, where the ADO library is not properly registered.

 

[dch3]

2. I have a good reason for not wanting to go straight into a full
conversion to SQL - one of the reasons Access has worked for us for ten years
is being able to make fast changes as our systems develop with no reference
to outside agencies. Its part used as a security tool that checks other
departments full size server databases for data errors and part used to
retain our own in house data. Hoping to use SQL server in future to secure
small video files we now open in Access from the file system and securing a
few but not all Access tables but still retain Access as a fully functional
front end.

1. You mentioned that this is a mission-critical application. *UPSIZE TO
SQLSERVER*. The fact that you haven't had any issues in the last ten years is
no guarantee that you won't have one. All it takes is one major incidient to
bring your organization to a halt. Prior to Hurrican Katrina hitting New
Orlenas, it had been countless years since the last incident.
2. SQL Server only replaces the backend. The front end is still
Access-based. You'd still be able to quickly make changes/enhancements.
3. Even if you're validating data against via other databases, Access
security *IS NOT* as reliable as SQLServer. Just because no ones broken into
your house in the last ten years, doesn't mean that you couldn't go home
tonight and find it robbed clean.

By default the MS DAO 3.6 library did not install and when I try
to install it it refuses to install because it conflicts with the
MS Office 12 Access Database Engine Library. Without DAO 3.6
large parts of my code fail to compile as I have always used DAO
in preference to ADO.

The MS Office 12 ADE library is really DAO [next version], and it is
fully backwardly compatible with DAO 3.6. You can't have both, and
you can't use 3.6. You should use only the ADE reference. If it
doesn't compile, then perhaps you have a problematic installation of
A2K7, where the ADO library is not properly registered.

 

[David W. Fenton]

1. The problem does not relate to a defective install of 2007. I
have tested that on my own systems.

Do you have some other problematic reference, then? You should try
to use as few references as possible.

2. I have a good reason for not wanting to go straight into a full
conversion to SQL

Er, who suggested that? Nobody with any sense! You should ignore
that kind of advice, because it's simply not helpful. It's like
morons who shout "Get a Mac!!!!" when a Windows user complains about
some problem.

one of the reasons Access has worked for us for ten years
is being able to make fast changes as our systems develop with no
reference to outside agencies. Its part used as a security tool
that checks other departments full size server databases for data
errors and part used to retain our own in house data. Hoping to
use SQL server in future to secure small video files we now open
in Access from the file system and securing a few but not all
Access tables but still retain Access as a fully functional front
end.

You're preaching to the choir here. Whoever it was who posted the BS
recommendation to upsize is not a credible poster here, and should
be ignored.

3. From the replies it points me at the fact that the database may
not have converted correctly from 2003 to 2007 using the convert
option, possibly due to the fact it was a secured database with a
lot of customization.

Converting from a secured MDB to an ACCDB would remove all security,
so I can't see how that could be an issue.

I did
wonder because I expected to lose the Add In ribbon with my old
menus when I converted and I can still open them in the accb. I
will try opening a new blank accb database and import the
converted objects to see what happens next. It is maybe overkill
because the original mdb after a bit of work on filters operates
OK in 2007. I am just trying to think ahead so they dont get
caught out with an obscelescent file system they cannnot upgrade
if I ever retire. Again thanks for the replies and has anybody
else come accross this problem.

Why convert to the new format at all?

 

[David W. Fenton]

1. You mentioned that this is a mission-critical application.
*UPSIZE TO SQLSERVER*.

That's a bloody stupid answer to a problem relating to a front end.
The issue raised by the original poster is not data-related -- it's
entirely front-end application-related.

[]

3. Even if you're validating data against via other databases,
Access security *IS NOT* as reliable as SQLServer.

Did you read the post at all? Do you know anything at all about
A2K7?

The original poster said the conversion was to ACCDB, WHICH DOES NOT
SUPPORT JET USER-LEVEL SECURITY.

Whoever you are, your posts are very like Aaron Kempf's in the depth
of their ignorance, and in their completely avoidance of any
relavance to the problems they are supposedly posted to solve.

If you can't offer anything that is relevant to the question, DON'T
POST ANYTHING AT ALL.

 

[merwcat]

Hi thanks for the replies they were all food for thought. The problem was
the mdb I used to convert, this was already running in office 2007 and still
retained all the custom form shortcut menus and toolbar menus I used
previously. Once I removed all of these it compiled with ADE instead of DAO
3.6 no problem. Hope this helps someone else.

1. Why convert to accb? - because I have the time to do it, I work for one
company alone and I eventually need to train someone to take over (we already
have people part trained who could do it if I dropped dead tomorrow). I
believe MS will continue to develop the accb format and I feel its better to
convert now rather than leave it to some one who is going to be on a large
learning curve anyway. Apart from that I can see a few interesting challenges
for me and some advantages.

2. Security - While I build the new system the old mdb is still in use and
still secured. I can see advantages to moving to accb secure encryption. I
believe I can adapt techniques I already use with workgroups to open the
encrypted file without revealing the password to the user and its opening
method. Shame to lose workgroup security but like everybody else I just move
on. My biggest worry was other insiders being able to make copies, workgroup
security was just one small part of the overall security setup which is why I
like the new secured encryption. USB/Cd Drives and email are all closed off
to 99% of the users and the only export ability are the reports and
information built in for export.

3. The drive for SQL is related to the IT people, they also see the need for
succession planning and would rather work with SQL themselves because they
understand maintaining it. I think Access is the correct database for the
size of data and type of work we do, its all inside a secured network anyway.
I can see some advantages to moving some stuff to SQL but I am in no rush. If
I do it I want to do it properly not end up building an insecure SQL server
by rushing into it when I already have a working Access system. Offered it
here as "thinking aloud for the best solution to the immediate problem". I
should maybe have left it out.

 

[dch3]

That's a bloody stupid answer to a problem relating to a front end.
The issue raised by the original poster is not data-related -- it's
entirely front-end application-related.

The original post stated that its a mission-critical application. I standby
my statement that the DB should be upsized to SQLServer. If you have any
questions, please, consider that I spent nine years working for Walt Disney
World operations (28,000 guest rooms, average daily hotel population of
65,000 guests) and *very* close collaboration with IT in regards to Disaster
Recovery, Business Continuity, and Downtime Procedures says otherwise.

Please feel free to take a moment and read the rules of conduct.
http://www.microsoft.com/office/community/en-us/default.mspx

 

[David W. Fenton]

1. Why convert to accb? - because I have the time to do it, I work
for one company alone and I eventually need to train someone to
take over (we already have people part trained who could do it if
I dropped dead tomorrow). I believe MS will continue to develop
the accb format and I feel its better to convert now rather than
leave it to some one who is going to be on a large learning curve
anyway. Apart from that I can see a few interesting challenges for
me and some advantages.

I think that's ill-advised. By that principle, you would have
switched from DAO to ADO in Access 2000, and now, 9 years later,
you'd be porting your ADO code back to DAO.

Now, the ACCDB is a better enhancement to Access, but I just don't
see any point in converting to it until there is an actual advantage
in doing so. Doing it just because it's new seems like a really
stupid justification to me.

2. Security - While I build the new system the old mdb is still
in use and still secured. I can see advantages to moving to accb
secure encryption.

There is no such thing, because all it offers is a database password
that you have to give to all the users.

Whetever the inadequacies of Jet user-level security with an MDB,
there is NO security at all in an ACCDB. The database password is
sham security and provides no protection at all (and lacks all the
user permission management capabilities that Jet ULS provides).

I
believe I can adapt techniques I already use with workgroups to
open the encrypted file without revealing the password to the user
and its opening method.

This will be safe only if you use an MDE/ADE front end and encrypt
that file, too, since all literals in VBA are written as literals
into the compiled p-code. That means that anyone with a hex editor
can read your passwords in an MDE or ADE.

Shame to lose workgroup security but like everybody else I just
move on.

It's one good reason *not* to move to the ACCDB format.

My biggest worry was other insiders being able to make copies,
workgroup security was just one small part of the overall security
setup which is why I like the new secured encryption.

I don't really think you have any understand of the new encryption.
It's good, strong encryption, but is usable only when you share a
password, or write the password into your application's code. This
is simply not a helpful feature.

USB/Cd Drives and email are all closed off
to 99% of the users and the only export ability are the reports
and information built in for export.

3. The drive for SQL is related to the IT people, they also see
the need for succession planning and would rather work with SQL
themselves because they understand maintaining it. I think Access
is the correct database for the size of data and type of work we
do, its all inside a secured network anyway.

If you need to secure the data, then SQL Server is really vastly
superior as a data store to a Jet MDB with ULS, and even *more*
superior to an ACCDB with a password. If security is the concern,
then, yes, SQL Server is a valid choice.

But it's rather orthogonal to my understanding of your original
question.

I can see some advantages to moving some stuff to SQL but I am in
no rush. If I do it I want to do it properly not end up building
an insecure SQL server by rushing into it when I already have a
working Access system. Offered it here as "thinking aloud for the
best solution to the immediate problem". I should maybe have left
it out.

I would say it depends on how much you value security. With an
ACCDB, you have none to speak of. With an MDB, you at least have Jet
ULS. If ACCDB is good enough for you, then you really don't need
security at all, in my opinion.

 

[David W. Fenton]

The original post stated that its a mission-critical application.
I standby my statement that the DB should be upsized to SQLServer.

Yet, the rest of the post provided a context that indicated that it
wasn't a use of the term "mission critical" that would justify the
need for SQL Server. You seem to have a knee-jerk reaction to the
term "mission critical" such that, rather than reading what was
actually written, you just fire off the SQL SERVER!!! SQL SERVER!!!
SQL SERVER!!! answer.

If you have any
questions, please, consider that I spent nine years working for
Walt Disney World operations (28,000 guest rooms, average daily
hotel population of 65,000 guests) and *very* close collaboration
with IT in regards to Disaster Recovery, Business Continuity, and
Downtime Procedures says otherwise.

So, you've got a big dick. Great.

Please feel free to take a moment and read the rules of conduct.
http://www.microsoft.com/office/community/en-us/default.mspx

What do those have to do with me? I don't use the MS website to post
to the MS newsgroups.

 

[dch3]

Yet, the rest of the post provided a context that indicated that it
wasn't a use of the term "mission critical" that would justify the
need for SQL Server. You seem to have a knee-jerk reaction to the
term "mission critical" such that, rather than reading what was
actually written, you just fire off the SQL SERVER!!! SQL SERVER!!!
SQL SERVER!!! answer.

If you were walking straight toward a train, but asking someone where the
nearest telephone was, I think you'd want to know that you were about to get
hit by a train. I take *QUITE* seriously anything that is labeled as
mission-critical. Just beacuse you disagree with my stance concerning the
neccessity to ensure business continuity, is no reason to berate me. Again,
please read the rules of conduct. I will *NOT* be responding further.

TO THE ORIGINAL POSTER: I stand by my original statement that you need to
upgrade to SQL Server. While Mr. Fenton obviously disagrees, I would highly
encourage you to make your own informed decision by pursuing a greater
understanding of the pros and cons of using Access and the pros and cons of
SQL Server - or another server-based product. I can only make the statement,
ultimately the decision to upsize or not is yours.

So, you've got a big dick. Great.


What do those have to do with me? I don't use the MS website to post
to the MS newsgroups.

I'm certain that whichever site you post to does have its own rules of
conduct which govern berating others. Again, I will *NOT* be responding to
this post further.

 

[David W. Fenton]

If you were walking straight toward a train, but asking someone
where the nearest telephone was, I think you'd want to know that
you were about to get hit by a train. I take *QUITE* seriously
anything that is labeled as mission-critical. Just beacuse you
disagree with my stance concerning the neccessity to ensure
business continuity, is no reason to berate me.

Get a thicker skin -- the response you've received from me is pretty
mild because all I've done is called BS on your non-responsive
answers.

Again,
please read the rules of conduct. I will *NOT* be responding
further.

What "rules of conduct" are you talking about? Do you have any
understanding at all of Usenet?

[]

I'm certain that whichever site you post to does have its own
rules of conduct which govern berating others.

If you're interested in looking it up and reporting me, I'm posting
through newsguy.com.

I doubt they'd find that I'd berated anyone -- all I've done is
pointed out that you're posting non-responsive answers that are BS.

Again, I will *NOT* be responding to
this post further.

Ah, in other words, you can't dispute what I've said so you're going
to slink away back into hiding.