Alison Balteramp;#039;s Mastering Microsoft Office Access 1002003 [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Alison Balteramp;#039;s Mastering Microsoft Office Access 1002003 [Electronic resources] - نسخه متنی

Alison Balter

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید



Preparing a Database to Be a Library


Creating a library database involves two steps:


  • Writing the functions and creating the objects to be included in the library

  • Loading the database as a library


  • You begin by creating the generic objects you want to share among your applications. To load the database as a library, you must reference it from another database. The next section covers this process.

    Before you can reference a database as a library, you need to think about how to construct the database so that it best serves you as a library. Although a library database is just a normal database, planning the design of the library is integral to its success and usefulness. Improper planning can cause numerous problems, from the need for extra memory to a database malfunction.

    Structuring Code Modules for Optimal Performance


    Library databases contain the general functions that you use in most of your applications. Because of the way Access loads code modules, you must structure your library databases effectively to achieve optimal performance.

    Access 2.0 loaded all code modules the moment the user loaded the application. This meant that, when developing an Access 2.0 application, it was not particularly important how you structured your subroutines and functions within the various modules of the database. This situation changed dramatically with Access 95 and all versions that followed it, all of which load code modules only if they are needed. In Access 95 and later, if your code does not call any procedures within a particular module, Access never loads the module into memory. On the other hand, if your code calls a single subroutine or function, or if your code references a public variable, Access loads the entire module. Therefore, it is crucial that you structure your modules to minimize what is loaded into memory, using these techniques:

    • Separate frequently used procedures from those that you call infrequently.

    • Place in the same module procedures that you use together.

    • Place in their own modules procedures that you rarely call.

    • If you call the same procedure by routines in more than one module, consider duplicating the routine and placing a copy of it in each module. This method prevents an entire module from loading just because you call a single routine within it.

    • Place in the same module procedures within a call tree. This is necessary because Access looks at the potential call tree when it loads a module. If a procedure in one module calls a procedure from another module, Access loads both modules into memory.


    Although you generally want to load as little as possible into memory, the opposite is true for commonly used functions. By placing frequently used procedures in the same module, you ensure that Access loads them into memory, so that it can access them quickly when you call them. This improves the performance of your application.

    Writing Library Code That Runs


    Code that runs perfectly within a normal database might not run as expected when it is part of a library database. Good examples are the CurrentProject object and the CurrentDB function. As you have seen throughout this book, the CurrentProject object is an object that refers to the current ADP project or Access database (mdb). The CurrentDB function is a commonly used function that enables you to reference the current database. You would think that both the CurrentProject object and the CurrentDB function reference the database in which the code is running, but this is actually not the case. They specifically reference the database that is active in the user interface. If a library function refers to either CurrentProject or CurrentDB, it does not refer to itself; instead, it refers to the application database that is calling the library function. If you want to refer to the library database, you must use the CodeProject object or the CodeDB function. The CodeProject object and the CodeDB function always refer to the database in which the code is running. You must decide whether CurrentProject, CurrentDB, CodeProject, or CodeDB is applicable for each situation.

    Compiling the Library


    Compiling a library database before you distribute it ensures optimal performance. If you do not compile the library code, Access will compile it each time you access it, which significantly degrades the performance of your application. Chapter 17, "Optimizing Your Application," covers the compilation process and its benefits. After you complete all changes to the library database, select Debug, Compile. You must choose this command each time you make changes to the library database.


    / 544