mperez1216
asked on
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.
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.
OR recompile again using your own pc, the pc thats compiled the mdb the first time
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 ...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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 :)
Cheers
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 :)
Cheers
Another off-topic comment - rather than using DoCmd.DoMenuItem or RunCommand, you may find it more expedient to use:
Me.Dirty=False
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).
Me.Dirty=False
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).
ASKER
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
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.
"\\servername\share$\datab
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.
In response to LSMConsulting, here is the full syntax to the shortcut:
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE
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.
"\\servername\share$\datab
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.
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.
ASKER
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.
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,
Cheers!
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,
Cheers!
ASKER
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.
Thanks.
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.
Thanks.
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.
Cheers!
> 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.
Cheers!
ASKER
Thank you and that was why (first comments) I awarded you the points. Also, thanks for the add'l info.
try compact and repair