1. CONVERTING A SECURED DATABASE
The Access ACCDB file format
offers data encryption using a database password, but it does not
support user-level security that uses the workgroup information manager
(MDW) files. User-level security will be removed as the file is
converted to the 2007 ACCDB file format. So, if the application has
complex user-level security and permissions that you need to rely on,
you may choose to keep the data in the MDB file. In that case, you're
home free, at least for this part. Alternatively, you can implement a
different approach to security and user permissions.
As security issues have become more critical and
complex, new ways have been developed to protect the data and the
application while making it easier for users to work with diverse and
remote sources.
After considering the options, let's say you decided
to shed the user/group security (which is administered via a MDW file)
and take advantage of the benefits offered by the ACCDB format.
Switching to the new format removes user-level security and permissions
from the file(s). Access will automatically remove the security settings
so you can start clean when applying new security and interface
controls to the new ACCDB or ACCDE file.
Keep in mind that if the application relied on
user-level security to control who could enter, change, or view a
specific date, those types of controls are not an inherent feature in
the ACCDB format; so you will need to implement an alternative approach.
|
It's almost scary that it is so easy to remove
user-level security which not only limited who could open a file, but
also determined what data a user could see or change. It will be
important to have a plan for replacing the security and control features
before converting a database that relied on Access's user-level
security (MDW) to a ACCDB format.
|
To convert the database, use Access 2010 to log in to
the database as a user with full administrative permissions for all
database objects.
After the file is converted, close the application
and Access. You will then be able to open the new ACCDB file without
providing a password. However, if the application has custom user login
features, those will still be enabled. And, if macros weren't already
addressed, they will also need to be enabled. You may be quite surprised
to realize a file is open but nothing shows up. If that occurs, you
should look for an information bar — just under the Ribbon — that asks
about enabling macros. One click may have everything working smoothly.
1.1. Converting a Password-Protected Database
If a database is password protected, the password
protection must be removed before the database can be converted. You can
use the following steps to remove the password:
Open Access 2010 and click the File button.
Click Open and browse to the target database.
Select the target database.
Click the drop-down arrow to the right of the Open button.
In
the Password Required dialog box, provide the database password and
click OK. The database opens in exclusive mode, which enables you to
remove the database password requirement.
Click the File button again and choose Info on the left pane.
Choose Unset Database Password on the right pane.
Type the password into the dialog box and click OK.
1.2. Converting a Database with Password-Protected VBA
Unlike the experience using Access 2003 to convert a database with
password-protected VBA, the password is not required to convert to 2010.
With both 2010 and 2007, the file is converted and the password is
preserved. The password will still be required to view or work with
code. However, even if the VBA is secured, you (and others) will still
be able to work with macros because they are in the Access file rather
than the VBA project.
NOTE
There are mixed opinions
about using a password to protect the code. Many developers think that
using a password to protect the VBA is somewhat prone to corruption or
being locked out of the code so they prefer to use an MDE or ACCDE file.
2. CONVERTING A REPLICATED DATABASE
Replication is not supported in the ACCDB file
format. Instead, a more powerful and versatile alternative is offered
using SharePoint services. But, if you need to preserve the benefits
derived from replication, you can keep the Access 2000 and 2002−2003 MDB
files. In some cases, however, the benefits of converting to the ACCDB
file format will outweigh the benefits derived from replication. The
following outlines the process for essentially creating a new database.
And, as always, we recommend making copies of all files and data sets
before embarking on the process.
NOTE
It's best to work with a copy of the Design
Master after it has been fully synchronized, but the same process could
be used with a replica. The issue is that only the data and objects that
are in the file that you convert will be in the new ACCDB file. This
alone should alert you to the importance of using the fully synchronized
Design Master.
Here are some guidelines to note before you begin:
Hidden and System objects in the replica must be visible so you can access the fields when you are re-creating the database.
Create a copy of the database. This will require both Access 2010 and the version of Access that created the replica.
Make interim copies as you proceed and allow plenty of time and patience for testing and adding features.
In general, the process is to use the original
version of Access to display the hidden and system objects in the
replica file, and then use Access 2010 to create the new application by
importing the objects, except for the tables. The tables will be created
using Make Table queries.
You will need to use the original version of Access to follow these steps.
Open the replica, preferably the Design Master.
Select Tools 
Options on the menu bar. The Options dialog box opens.
On the View tab, be sure Hidden Objects and System Objects are both selected (checked).
Click OK to save the changes.
Close the database and Access. The file is now ready for the objects to be imported into a new Database Container.
Open Access 2010 and ensure that the default file format is ACCDB. Follow these steps to create a copy of the replica:
Create
a new blank database by selecting Blank Database and providing a
filename. Be sure to accept or select the ACCDB format, and then click
Create.
Delete the default Table 1 by closing it.
In the Import group on the External Data tab, click Access. The Get External Data dialog box opens.
Browse
to the folder containing the prepared replica file and select it by
either double-clicking or selecting the file and then clicking Open.
This returns you to the Get External Data dialog box.
Ensure
that you have selected Import Tables, Queries, Forms Reports, Macros
and Modules in the current database, and then click OK. The Import
Objects window will then open.
On
each tab, select the objects that you want to import. (If you want all
of the objects, use the Select All button on each tab.) When all of the
desired objects are selected, click OK. The wizard will import the
objects and then offer the opportunity to save the import steps.
Selecting
Yes enables you to give the process a name and description. If this
import process will be repeated on a regular basis, it could even be
scheduled as an Outlook task. After filling in the information, click
Save Import. The Import Objects window will then close.
All the objects except for the tables are imported. Name and save the database.
Open another instance of Access 2010 and open the prepared replica database.
In the Macro & Codes group on the Create tab, click Query Design. This opens a new query in Design view.
Select
the first table from the list, and click Add and then Close. The table
is added to the query design window. Double-click the table's title bar
to select all the fields, and then drag and drop the fields into the
query grid. Although you don't want the s_Lineage and s_Generation
fields in the new tables, the most efficient way to accomplish the task
is to drag all of the fields into the query grid and then delete these
two fields.
Click
Make Table Query. In the Make Table dialog box, select the current
table's name and then select Another Database. Browse to and select the
newly created ACCDB. Click OK.
Click Run to create the table in the new database.
NOTE
If s_GUID is the primary key and it is referred to by the foreign keys in other tables, then s_GUID must be included in the new tables. If s_GUID is not used to establish relationships between tables, it is not needed in the new tables.
The new tables do not inherit the field properties or
the primary key settings from the original database. Those need to be
manually re-created:
Open
a table in Design view. In the field list, select the field that should
be the primary key, and then click Primary Key in the Tools group.
In
the field list, select the field that requires an index. In the field's
Properties pane, click the Indexed drop-down and select either YES (Duplicates OK) (if some values are repeated) or YES (No Duplicates). Continue this procedure through all the tables.
Finally, establish the table relationships as they were in the replica:
Click Relationships on the Database Tools tab.
Add the appropriate tables to the relationships window.
Drag
a field from one table to another to create the relationship between
the tables based on those two fields. The Edit Relationships dialog box
enables you to enforce referential integrity and to specify a join type.
When the relationships are established, click Close to close the window
and return to the database objects.
Save and close the database. Make a copy and start testing.
As always, it is a good practice to split the database, either at this point or as soon as it is functioning properly.
