Bilbo_Baggins_Esq
Registered User.
- Local time
- Today, 07:26
- Joined
- Jul 5, 2007
- Messages
- 586
We are performing migrations of all Office files from the older formats to the newer formats.
We have an automated tool which, in addition to converting the format(s), reads the VBE projects and performs remediation of the existing code for deprecated objects, methods, and constants.
To perform this function, the automated tool cannot encounter any scenario where a password or permission is required.
We encountered a submitted mdb database where the automated tool could not perform edits.
My position is to support the team performing the automated functions as a backup when they encounter problems such as this.
When I first checked the database I noticed it has a startup action that loads a form but there was no specified form in the OnOpen section of the Options.
This told me there was an Autoexec macro.
I was easily able to bypass this by holding the shift key down while opening and the full database opens without loading the form.
I was easily able to determine there are several objects (tables, queries, forms, reports, modules, and macros) that have permissions required through the old style User/Group level permissions.
Not all of the objects had this requirement however.
Some of them had no permission requirements at all.
Additionally, at no time during my initial investigation did any dialog fire to prompt for a login ID or password.
I reported my findings back to the automated team and the submitter of the database who promptly began arguing with me that no permissions should be required because he performs all of his work with none.
Ugh, that is a whole other story.
The fact remains despite whatever other objects he was working with that did not require any permissions, the core elements of the database did and do have permissions required to make changes.
During the course of argument, I joined a communicator session with the submitter to prove to him permissions were required for some of the objects.
I opened his local copy of the database while holding the shift key down.
We were both immediately presented with an old style login in dialog box which I had not seen on my copy of the database.
Needless to say, this finally proved to the submitter the truth of what I was saying, but left us with a problem: how to get logged in.
This database is very old and none of the original admins or developers are around.
Apparently, over time, some new objects like tables and queries and forms and reports have been added to the database which did not have any permissions applied to them
Over time, the so-called “owner” of the database commonly would build new pieces and merely refer back to the permissioned objects without ever the need to change their design or to login.
On his version of the database, bypassing the Autoexec seems to have prompted the login.
Somehow, he was able to locate and obtain a set of login credentials and reported back to me.
We joined another communicator session wherein we were able to successfully log in on an account.
I opened the users/groups dialog to examine the permissions applied with the objective of removing them.
Here is where I made my first mistake (inadverdently).
I had opened the customer original database, not a copy.
Even though I clicked cancel in the users/groups dialog, something did get changed because now when opening the database (holding shift) there is no prompt for login credentials. It just behaves now exactly like my version (the version that was originally submitted).
Initially, I did not necessarily think this would be a problem as I knew I could simply create a new blank database and import copies of all the objects from the old database.
I have since been able to successfully import all of the database tables, forms, reports, and query objects from the permissioned database into a new and clean mdb.
However, the import process would not let me import the modules or the macros due to lacking permissions to do so.
So, I was able to open the modules in the VBE and copy/paste the code into a new module in the replacement database and then apply the origin module name to the module in the replacement database. This too was not any problem.
(BTW: I performed all of this with "Track name changes" turned off in the new database)
However, Access will still not let me open (in design view) or copy/export/import the macros.
So, I seem to be forced back to a position where I need to figure out how I can return the database (either my copy or the submitter’s copy) to a state where it will prompt for login credentials.
Of course, the ultimate goal is to get the last remaining macro objects into the new database, but I have no desire to hack or use other unscrupulous means to achieve this.
I do believe, once I can get the credentials dialog to fire that I can use the known credentials to get logged in and open or export the macros to the replacement database.
If the permissions are retained, then I can simply open them each in design view and recreate them manually.
But the key is, getting the credentials dialog to fire.
So, after this long explanation of why, here is the whole question:
How can I re-enable a database that has permissions required for some objects to prompt for login credentials.
Any Ideas?
We have an automated tool which, in addition to converting the format(s), reads the VBE projects and performs remediation of the existing code for deprecated objects, methods, and constants.
To perform this function, the automated tool cannot encounter any scenario where a password or permission is required.
We encountered a submitted mdb database where the automated tool could not perform edits.
My position is to support the team performing the automated functions as a backup when they encounter problems such as this.
When I first checked the database I noticed it has a startup action that loads a form but there was no specified form in the OnOpen section of the Options.
This told me there was an Autoexec macro.
I was easily able to bypass this by holding the shift key down while opening and the full database opens without loading the form.
I was easily able to determine there are several objects (tables, queries, forms, reports, modules, and macros) that have permissions required through the old style User/Group level permissions.
Not all of the objects had this requirement however.
Some of them had no permission requirements at all.
Additionally, at no time during my initial investigation did any dialog fire to prompt for a login ID or password.
I reported my findings back to the automated team and the submitter of the database who promptly began arguing with me that no permissions should be required because he performs all of his work with none.
Ugh, that is a whole other story.
The fact remains despite whatever other objects he was working with that did not require any permissions, the core elements of the database did and do have permissions required to make changes.
During the course of argument, I joined a communicator session with the submitter to prove to him permissions were required for some of the objects.
I opened his local copy of the database while holding the shift key down.
We were both immediately presented with an old style login in dialog box which I had not seen on my copy of the database.
Needless to say, this finally proved to the submitter the truth of what I was saying, but left us with a problem: how to get logged in.
This database is very old and none of the original admins or developers are around.
Apparently, over time, some new objects like tables and queries and forms and reports have been added to the database which did not have any permissions applied to them
Over time, the so-called “owner” of the database commonly would build new pieces and merely refer back to the permissioned objects without ever the need to change their design or to login.
On his version of the database, bypassing the Autoexec seems to have prompted the login.
Somehow, he was able to locate and obtain a set of login credentials and reported back to me.
We joined another communicator session wherein we were able to successfully log in on an account.
I opened the users/groups dialog to examine the permissions applied with the objective of removing them.
Here is where I made my first mistake (inadverdently).
I had opened the customer original database, not a copy.
Even though I clicked cancel in the users/groups dialog, something did get changed because now when opening the database (holding shift) there is no prompt for login credentials. It just behaves now exactly like my version (the version that was originally submitted).
Initially, I did not necessarily think this would be a problem as I knew I could simply create a new blank database and import copies of all the objects from the old database.
I have since been able to successfully import all of the database tables, forms, reports, and query objects from the permissioned database into a new and clean mdb.
However, the import process would not let me import the modules or the macros due to lacking permissions to do so.
So, I was able to open the modules in the VBE and copy/paste the code into a new module in the replacement database and then apply the origin module name to the module in the replacement database. This too was not any problem.
(BTW: I performed all of this with "Track name changes" turned off in the new database)
However, Access will still not let me open (in design view) or copy/export/import the macros.
So, I seem to be forced back to a position where I need to figure out how I can return the database (either my copy or the submitter’s copy) to a state where it will prompt for login credentials.
Of course, the ultimate goal is to get the last remaining macro objects into the new database, but I have no desire to hack or use other unscrupulous means to achieve this.
I do believe, once I can get the credentials dialog to fire that I can use the known credentials to get logged in and open or export the macros to the replacement database.
If the permissions are retained, then I can simply open them each in design view and recreate them manually.
But the key is, getting the credentials dialog to fire.
So, after this long explanation of why, here is the whole question:
How can I re-enable a database that has permissions required for some objects to prompt for login credentials.
Any Ideas?