The current user account doesn't have permission to convert or enable this database.

Hello, all.

I have an Access97 secured database which I was able to open in Access 2000 and Access 2002 (Office XP). Using a client's workstation that is running Access97, I made a minor change to a form (adding a Me.Undo statement whening exiting the form). Also, besides adding the Me.Undo statement, I added the following code

DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70

prior to the closing the form command.

Compiled the module, saved the form, and exited the database.

Users running Access97 don't have a problem, but users running Access 2000 or 2002, see following message:

To convert or enable a database, ensure the following:
* You must join the workgroup that defines the user accounts used to access the database.
Yada, Yada, Yada.

In other postings, the suggestion was to convert the database to the 2000 or 2002. This cannot be done at this time since most of the users are still running Access97, so I don't believe this to be a valid solution. AND, I was able to open this database in the past with no problem, including this morning! How can making a minor change in a form cause this problem?

I don't believe that entering the Me.Undo command caused the problem as after I created the command, I opened the database with Access2002 and was able to test this. But after adding the DoCmd.....acSaveRecord, that was when I was no longer able to open the database.

I have since then removed this entry, but I am still unable to open the database. I even went so far as to create the shortcut that logs me into the database with the workgroup file and still, no access.

Please note that any changes that are made are always made using the Access97 client.

Any suggestions on what I might have missed? Thanks.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

the only thing that comes to my mind is
try compact and repair
OR recompile again using your own pc, the pc thats compiled the mdb the first time
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
What's the full syntax of your shortcut? Sounds like you're either (a) not opening the db with the correct workgroup of (b) not opening the db with an account that has permission to convert the db (this on the 2000/2002 machines). In order to convert your db in a secured app, the user with which you login must have the rights to convert the database ... easiest solution would be to login to the db on with 2000 (using a login with sufficient permissions to convert the database, IOW a member of the Admins group), convert the database, then distribute that database ...
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

You are saying "secure", but how secure is that? Did you remove all rights to the group "Users", created "Guru" replacing "Admin", etc?
I trust that when you say "it worked fine before, not anymore", that is exaclty what happened.

The only side effect of "modifying a form on a user's computer" is that the owner changed. So please open (in Access 97) "Tools / Security / User and Group Permissions", find the form that has been modified and compare it with others. Also open the "Owner" tab and compare.

Once you have done this, post the result here.

Another path is the "convert" business.

If you have both Access97 and Access200x users, the database must be "enabled" for higher versions. This in effect locks the database objects for editing. It might very well be that you need to compile, repair, compact your database, then open Access 2000 *with the correct workgroup file*, enable for that version and close. Perhaps you changed has removed the "enabled" flag for higher versions?

If that is in fact the problem, consider changing to a more professional Front-end/Back-end architecture. Put all the tables in one Access97 database, and all other objects in another. Link the tables from the first into the second. If you are not using things like "OpenRecordset("...", dbOpenTable)" or the like, it will work exactly as before.

Now you will keep this second databse as "SOURCE", in which you will make the changes. After each round of changes/testing/validation:
- Create an Access 97 MDE file
- Convert to Access 2000 and create an Access 2000 MDE file
- Convert ot Access 2003 and create an Access 2003 MDE file
- Distribute the MDE files for the users.

I'm sure we will figure this one out...
Good luck!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Some other more or less off-topic comments:

The command:
    DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70
is obsolete and not very readable. Replace with
    RunCommand acCmdSaveRecord

Also I am wondering what exacly you were doing...

- Me.Undo before closing the form... (i.e. not saving)
- Running Save Record before closing (which Access would do anyways)...

These seem both strange and contradictory! But never mind, this is none of my  business :)

Another off-topic comment - rather than using DoCmd.DoMenuItem or RunCommand, you may find it more expedient to use:

Me can be replaced with any form reference and it does not require the form in question to have the focus (or even be visible, come to that). You can also use the Dirty property to check if any data has been changed that requires a save (it will be True if that is the case).
mperez1216Author Commented:
In response to jjafferr, already tried compact and repair with no change in status.

In response to LSMConsulting, here is the full syntax to the shortcut:

"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" /wrkgrp "\\servername\share$\wrkgrpfile.mdw"

This shortcut is only used when I, and I alone, need to make changes to the database as the admin using ACC97. Otherwise, endusers use this shortcut below to open the database. They (the endusers) do not use the wrkgrp file and they (the endusers) do not have any problems opening the database using ACC97.


Again, the intent is NOT to convert the database, as most endusers are still on ACC97. Only a few individuals are using ACC2000 or ACC2002. In the end, all will be at ACC2002, but that won't be until for a while.

In response to harfang, yes, I had already modify the groups' rights. I will need to obtain the other information as far as finding ownership.

I already have the tables in one db1 and the queries, forms, & reports in db2. The tables are linked from db1 into db2. DB2 is the database that I am now having problems with after making some changes.

As far as the DoCmd.DoMenuItem reference,  this was just merely a way of saving the record when the enduser selected a button that will run another set of steps. I have not used the RunCommand statement. Will try that also.

As far as the Me.Undo statement, I needed a way not to save a record when an enduser started to fill out a form, but then changes his mind and exits the form. I far as I understand (please correct me if I am incorrect), Access automatically saves a record when you exit a form UNLESS you press the {ESC} key a couple of times.

Didn't know of the Me.Dirty command, since I have never used it. What exactly does it do?
Would I replace the Me.Undo with Me.Dirty=False or am I to insert additional code to check for it?

If so, how would the syntax go?

Hope this info helps.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
You've either got to convert it or "enable" your 97-format database for 2000+ users to be able to do this, and those users MUST have the correct permissions to do this. Are your 2000+ users joined to the wrkgrpfile.mdw workgroup file? Are they logging in with a username with sufficient permissions to convert/enable the 97 version? From the error you're receiving, I'd bet not.

mperez1216Author Commented:
I am not too clear on "enabling" the ACC97 database. I will have to double-check the permissions, though.

Maybe something got changed when I last maintained it.
Thank you for the precisions, although off-topic, your comments are quite right.

Keep using Me.Undo and DoCmd / RunCommand for canceling and saving your data. Leave the Me.Dirty assignment for now (although you might use "If Me.Dirty Then ..." to check whether the current record has been changed if you need that.

Yes, you are correct, Access will attempt to save edits whenever you leave the record, whatever the means, which include closing the form.

As for enabling:

Normally, the program and the data always need to have the same version. For example, if you read an old Word95 document with your Word2000 program, it will have to convert the old file before you can do anything with it. In Access, things are a little more complex, because the conversion isn't that easy to begin with and because the data can - and often is - shared by many users.

Whe you use Access 2000 to open an Access 97 database, you can do one of two things, both requiring full rights to the database.
1) Converting
Access 2000 will create a new database, import all '97 objects, attempt a compilation, and compact. This database can then be used by any other Access 2000 user, even with lesser rights, but not by  Access 97. Access 2000 users can also modify objects or creating new ones, depending on the detailed rights.
2) Enabling
Access 2000 will inspect the database, set a series of compatibility flags to forms, reports and macros (allowing it to execute correctly the objects) and instruct VB similarily for the modules. This information is stored in the Access 97 database. After enabling, both Access 2000 and Access 97 users can use the database with lesser rights, but not modify and Access object.

External datafiles (linked tables) are not directly openend by Access per se, but by the JetEngine. They do not need to be converted or enabled. In fact, each database has *two* version numbers, one for the tables and queries (JetEngine version), and another for the remaining objects (Access version).

Workgroup information files store only tables and can also be used without converting/enabling.

In order for you Access 97 application to work again on all machines, follow these steps:

1) Open Access 2000 with the shortcut connecting to the workgroup information file and, if needed, as the actual owner of the database (add "/user <name>" to the shortcut). Enter the required password if prompted.
2) Open your "DB2" (the application).
3) When prompted, enable the application for use by Access 2000.
4) Close.

If you see the message "you do not have the ..... to convert or enable the database", this means that you do not have the proper workgroup information file or that you are not connected as the proper user.

Again, in the long run, consider creating different front-end application versions for the various versions of Access (e.g. "DB2-97", "DB2-2k", "DB2-XP"). You will have better performance.

I hope this will solve the problem,

mperez1216Author Commented:
I will tell you all why I awarded Harfang the points.

Again, I had modified the forms before getting the error message. Harfang led me towards double-checking the Security settings in the database. It turned out that the forms in question had changed ownership. Why they changed is still the question. I set them back to what they were before and BAM! I'm back in business.


Not to be picky, but my first comment included:
> The only side effect of "modifying a form on a user's computer" is that the owner changed
This means that my very first ideas was correct :)

As to "Why they changed is still the question" it has a very good reason:
SQL has an option called "WITH OWNERACCESS OPTION" that is used the following way:

Imagine a table of Employees, containing some semi-confidential fields along with "public" fields. To protect that data somewhat, the developper might remove read access to the table for the Users group. In the general "public" form, all users should be able to see the "public" fields... So:

    SELECT <list of public fields> FROM tblEmployees WITH OWNERACCESS OPTION

The form's owner is Guru (all rights) and the read/write rights to the *Form* are granted to Users. Everyone can run the form, and Access will display the "public" fields using Guru's rights.

Now a regular user goes into design mode and adds some fields to the query. See the problem? For this reason, Access will automatically change the owner to the current user when entering design mode. Simple, efficient, and VERY reasonable.

So you have the theoretical background as well, now.

mperez1216Author Commented:
Thank you and that was why (first comments) I awarded you the points. Also, thanks for the add'l info.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.