Now that you are familiar with library databases and what they offer, try extracting all the generic functions from an application and placing them in a library database. This section presents a step-by-step roadmap for accomplishing this task.
NOTE
This process already has been completed for CHAP24.MDB. The associated library database is called CHAP24LIB.MDA. If you want to complete this process as an exercise, copy CHAP24.MDB and complete the outlined steps.
To extract the generic functions from the Time and Billing application and place them in a library database, follow these steps:
Create a new database that will become the library database. Import the basUtils, basGenericErrorHandler, and basWinAPI modules as well as the frmError form into the library database.
Remove two routines from basUtils within the library database: RunReport and GetCompanyInfo. Assume that these routines are specific to the application database and should not be moved to become a part of the library.
Choose Debug, Compile to ensure that you do not get any compile errors in the library database.
Open the application database.
Remove basGenericErrorHandler, basWinAPI, and frmError from the application database.
Remove six subroutines from basUtils in the application database: IsLoaded, FlipEnabled, ImportantKey, AreTablesAttached, LastOccurence, and TryAgain.
Choose Tools, References to reference the library database.
Choose Debug, Compile to ensure that you do not get any compile errors in the application database.
Test the application to ensure that it runs successfully. To properly check all aspects of the application, you need to introduce an error to test the error-handling routines. Rename the CHAP24DATA.MDB database to test the linking routines.
You should move one more database element to the library database: the Report Selection Criteria form. This form is generic and you can therefore use it in many of the applications you create.
Follow these steps to move the frmReportDateRange form to the library database:
Open the library database and import the frmReportDateRange form.
Create a module called basGenericForms and add the OpenReportDateRange subroutine to the module. Because you cannot open a form in a library database directly, you must create a routine within the library database that opens the form.
Open the application database and remove the frmReportDateRange form.
Modify the appropriate objects within the application database like this:
Sub OpenReportDateRange(strOpenArg As String) DoCmd.OpenForm "frmReportDateRange", , , , , acDialog, _ strOpenArg End Sub
You must modify three reports in the application database to accommodate the movement of the frmReportDateRange form to a library database: rptProjectBillingsByWorkCode, rptClientBillingsByProject, and rptEmployeeBillingsByProject. You must modify the Open event of the rptProjectBillingsByWorkCode report to look like this:
Private Sub Report_Open(Cancel As Integer) Call OpenReportDateRange("rptProjectBillingsByWorkCode") If Not IsLoaded("frmReportDateRange") Then Cancel = True End If End Sub
Instead of opening the form directly, which would not work because the form is in a library database, you must call the OpenReportDateRange library routine to open the form. The code uses the strOpenArg parameter to the OpenReportDateRange subroutine as the OpenArgs parameter for the frmReportCriteria form. You must make similar changes to the rptClientBillingsByProject and rptEmployeeBillingsByProject reports. You should modify the Open event of the rptClientBillingsByProject report to look like Listing 24.3.
Modify the Open event of the rptEmployeeBillingsByProject report to look like this:
Private Sub Report_Open(Cancel As Integer) Call OpenReportDateRange("rptEmployeeBillingsByProject") If Not IsLoaded("frmReportDateRange") Then Cancel = True End If End Sub
After you move the generic features of the application to the library database, you can try to build another application database and use the same library features.