Microsoft Access Readme Help Contents

Main Help Contents

Microsoft Access Product Update

Late-breaking information about this release of Microsoft Access.

Conversion and Compatibility Updates

Late-breaking issues on converting databases from Microsoft Access version 1.x to version 2.0, compatibility between versions of Microsoft Access, and compatibility between Microsoft Access version 2.0 and Visual Basic.  For additional information about converting your version 1.x databases, see Chapter 1, "Setting Up Microsoft Access," of the Microsoft Access User's Guide.

Network Installations

Instructions for installing Microsoft Access to run on a network and for saving a custom setup for your organization.

Documentation Updates

Late-breaking changes and additions to Microsoft Access documentation.

Using Microsoft Access Version 2.0 with Other Software

Instructions and tips on using Microsoft Access version 2.0 with Microsoft Visual Basic, Microsoft Word and Microsoft Excel, Paradox, Microsoft FoxPro, Lotus cc:Mail or Lotus Notes, Microsoft Video for Windows, Windows NT, Novell NetWare, Microsoft LAN Manager, Microsoft Windows for Workgroups, SQL Server, and ORACLE Server.

Using Microsoft Access with Btrieve

Information on configuring Btrieve for use with Microsoft Access.

Files Included with Microsoft Access

Describes all the files included with Microsoft Access.

To print a Readme Help topic

1	Display the topic you want in the Help window.

2	From the File menu in the Help window, choose Print Topic.


Microsoft Access Product Update

Contents

Microsoft Access Q&A

Using SHARE.EXE or VSHARE.386

Using DECOMP.EXE to Decompress Microsoft Access Files

Renaming, Deleting, or Moving Files and Directories

Files That Must Be Installed Locally

Warning When Attaching Tables with Unsupported Indexes

Scope and Lifetime of Access Basic Variables and Functions

International Issues

Microsoft Access Q&A

The Microsoft Access Help file includes answers for the most frequently asked questions about Microsoft Access.  To view these, search Microsoft Access Help for "common questions."

Using SHARE.EXE or VSHARE.386

To set up and run Microsoft Access version 2.0, you must use some version of file locking.  If you are running Microsoft Windows in standard mode (the default for 80286 or lower microprocessors), this is accomplished using the SHARE.EXE program supplied with your version of MS-DOS or PC-DOS.  The Microsoft Access Setup program will automatically modify your AUTOEXEC.BAT file to use SHARE.EXE.  (SHARE.EXE must be in a directory on the DOS path.)

If you are running Microsoft Windows in enhanced mode (the default for 80386 or higher microprocessors), the Microsoft Access Setup program will automatically upgrade your file locking by loading the VSHARE.386 file-locking driver.  The Setup program adds the following line to your SYSTEM.INI file (if it's not already there):

device=vshare.386

If you are running Windows in standard mode, you may need to add the following line to your AUTOEXEC.BAT file if it was removed or if Setup was unable to add it:

<path>\share.exe /l:500 /f:5100

where <path> is the drive and directory where the SHARE.EXE file is located (usually the MS-DOS directory).  For example, if your MS-DOS directory is called DOS and is on drive C, add the following line to your AUTOEXEC.BAT file:

c:\dos\share.exe /l:500 /f:5100

When the Setup program makes these changes to the SHARE.EXE line in the AUTOEXEC.BAT file, it may cause problems if you are using a third-party memory manager program.  (Microsoft Access will run correctly, but the memory manager may not run, or may not be optimized.)  If SHARE.EXE was loaded by a third-party memory manager, check the SHARE.EXE line in the AUTOEXEC.BAT file, and make sure the /l and /f options are set to values at least as high as those shown in the preceding examples.

If you have a multiconfiguration system (for example, if you are using this feature in MS-DOS 6.x), the Setup program will configure file locking only for the first instance it encounters.  If you want the Setup program to configure file locking for later instances, these instances must be modified manually.

To determine what mode you are running in, choose the About Program Manager command from the Help menu in the Windows Program Manager.

Using DECOMP.EXE to Decompress Microsoft Access Files

Microsoft Access includes a decompression utility, DECOMP.EXE, on Disk 1 in your Microsoft Access package.  You can use DECOMP.EXE to decompress files without running Setup.  This allows you to install individual Microsoft Access files.  DECOMP.EXE uses the following syntax:

DECOMP <source> <destination>

The <source> argument specifies the file or files to be decompressed; it can be a file name or include wildcard characters.  The <destination> argument is the name of the decompressed file or directory.

Copy DECOMP.EXE to your hard disk, so you can use it to decompress files from any of the Microsoft Access disks.

Renaming, Deleting, or Moving Files and Directories

You may get unpredictable results if you do any of the following after you install Microsoft Access:

Rename the directory into which you installed Microsoft Access

Delete or move any .INI files

Delete or move any .DLL files

Delete or move any of the subdirectories in the Microsoft Access directory

If you want to change your Microsoft Access installation, rerun Microsoft Access Setup from the MS Access Setup icon in the Microsoft Access program group.  Choose the Add/Remove button, and then follow the instructions in Setup.  If you chose a Minimal installation when you last installed Microsoft Access, you'll need to run Setup from the Microsoft Access disks.

Files That Must Be Installed Locally

Regardless of the Setup options you choose, Setup must install certain files in your Windows and Windows system directories on your computer's local hard disk.  For a full list of these files, see Files Included with Microsoft Access.  If your computer's hard disk does not have enough space for these files, you will not be able to complete Setup.

Warning When Attaching Tables with Unsupported Indexes

If you attach an indexed external table in another database format, such as Microsoft FoxPro, and you modify indexed data in the attached table with Microsoft Access, it's possible that Microsoft Access may not properly maintain your attached indexes, causing unexpected results.  If you want Microsoft Access to display a warning message when you try to attach such tables, add the following line to the [Options] section of your MSACC20.INI file:

AttachIndexWarning=Yes

If the [Options] section does not already exist in your MSACC20.INI file, you will have to create it.

This situation can occur if Microsoft Access doesn't recognize the collating sequence of a table you attach.  (For example, this may happen as new versions of other products are released, until Microsoft Access is able to update the driver files.)  This situation can also occur if the attached table contains indexes that Microsoft Access can't maintain (for example, if an index expression contains a reference to a user-defined function or variable, or if an index expression uses a function not supported by Microsoft Access).

If you do modify such indexed data, and the indexes are not maintained, you will have to close the Microsoft Access database, open the table in the original database format and recreate the indexes, and then reopen the Microsoft Access database.

Scope and Lifetime of Access Basic Variables and Functions

The way Access Basic handles the scope and lifetime of variables and functions can cause unexpected results in some circumstances.  Make sure variables are declared where necessary as global variables or using the Static reserved word, and that functions are declared where necessary in global modules.

For example, a variable declared as a Database object in a Sub or Function procedure by default exists only while the procedure is executing.  As a result, references to any data access objects in the database are invalid after the procedure stops executing, even if they're represented by global variables.  In the following example, the global recordset variable MyRs is invalid after the procedure stops executing:

Sub TestRecordset()

Dim MyDb As Database

Set MyDb = DBEngine.Workspaces(0).Databases(0)
Set MyRs = MyDb.OpenRecordset("Categories")

End Sub

To avoid this problem, declare the Database variable as a global variable or use the Static reserved word in the declaration.  For example, you could revise the preceding procedure as follows:

Sub TestRecordset()

Dim MyDb As Static Database

Set MyDb = DBEngine.Workspaces(0).Databases(0)
Set MyRs = MyDb.OpenRecordset("Categories")

End Sub

Similarly, a user-defined function that is used as an argument to an Access Basic function must be declared in a global module rather than in a form or report module.  Access Basic can't evaluate a form or report module function passed as an Access Basic function argument because a form or report module's procedures are private to that form or report.  Access Basic functions, by contrast, are evaluated at the module level.

For example, the following function call on the MyForm form produces an error if the MyFunc function is in the MyForm form's module:

Sum(MyFunc())

International Issues

If you're using a Hungarian or Czech database and you attempt to use the Like operator or the InStr function (on a nonindexed field), you won't find a match for several characters:

Hungarian:

DZ, DZS, CS, GY, LY, NY, OZS, SZ, TY, ZS

Czech:

CH

The preceding characters are contractions:  characters that are considered as one character.  Microsoft Access will sort these characters correctly, but any attempt to use the Like operator or the InStr function on these characters (such as:  Like "DZ*") will not result in a match even if a match exists.


Conversion and Compatibility Updates

Contents

Conversion from Microsoft Access Version 1.x to 2.0

Setup Removes Microsoft Access Version 1.x Files

Improving Index Performance

Conflicts with New Property Names in Expressions and Access Basic Code

Form Control and Section Names

Converting a "Front-end/Back-end" Application

Version 2.0 Setup and the UTILITY.MDA File

Using Visual Basic Version 3.0 Applications

Exporting to Version 1.1 Databases

DefaultValue Property Setting Includes Quotation Marks in Version 2.0

Owner Access Queries

Order of Evaluation of Expressions

Applications That Use the SQL Pass-through DLL

Closing Pop-up Forms and Their Underlying Windows

Unused Error Messages

Conversion from Microsoft Access Version 1.x to 2.0

See Chapter 1, "Setting Up Microsoft Access," of the Microsoft Access User's Guide for information about converting files from a previous version of Microsoft Access.  After conversion, open and resave all database objects except for tables, and run all queries.  This will improve performance.  (Tables are converted and resaved automatically during the conversion process.)

Note that if you optimized your Microsoft Access database for performance in version 1.x, you may need to reevaluate and adjust the optimization in version 2.0.  For more information, search Microsoft Access Help for "optimizing performance."

Setup Removes Microsoft Access Version 1.x Files

If you install Microsoft Access version 2.0 into a directory that contained a previous version of Microsoft Access, Setup will replace or remove most version 1.x files.  This applies only to application files, not your data files such as databases.  Files shared by other applications, such as Graph version 5.0 files, will also not be removed.

Improving Index Performance

Microsoft Access version 2.0 handles indexes differently than version 1.x, and with much better performance.  You may want to modify your indexes after you convert a version 1.x database to optimize performance.  For more information, search Microsoft Access Help for "performance," "Rushmore technology," and "indexes: creating."

Conflicts with New Property Names in Expressions and Access Basic Code

Microsoft Access version 2.0 includes many new properties for objects.  If you have a field, control, or other object in a version 1.x database with the same name as a new property, references to the object in macros, expressions, or Access Basic may conflict with the new property name after you convert your database.  You can fix the conflicts by using the full syntax in the reference.

For example, suppose you use a macro in a version 1.x database to set the value of a field or control named Name.  The macro contains a SetValue action with the Item argument set to [Name].  In the version 1.x database, the macro sets the value of the field or control.  However, version 2.0 includes a new property for tables and forms called Name.  After you convert the database to version 2.0 format, your macro tries to set the value of the table or form's Name property rather than the field or control.  This property is read-only, so the macro produces an error.

You can fix such references by using the full syntax, such as this:

People!Name	(to set the value of the Name field in the People table)

Forms!People!Name	(to set the value of the Name control in the People form)

In addition, if you used the .(dot) operator instead of an !(exclamation point) in a reference to the field or object with the same name as a new property, after converting the database your reference returns the setting of the new property instead of the value of the field or object.  For example, in a version 1.x database, this returns the value in the Name field in the People table:

People.Name

After you convert the database, it refers to the Name property of the People table.  To fix the reference, replace the .(dot) operator with the ! operator:

People!Name

You should always use an ! (exclamation point) rather than a .(dot) when referring to forms, reports, fields, and controls.  See Identifiers in Expressions for more information.

You cannot refer to the new properties as properties in a version 1.x database.  These properties are only visible to Microsoft Access in a version 2.0 database.

For a list of all the new property names, search Help for "properties: reference." In the alphabetical listing of all properties, new properties are marked with an * (asterisk).

Form Control and Section Names

In Microsoft Access version 2.0, a control and a section on a form can't have the same name.  Also, sections and controls can't use "Form" or "Report" as a name.  If you named a control "Form" or "Report" when using Microsoft Access version 1.x, you must rename the control before you convert to Microsoft Access version 2.0.

Converting a "Front-end/Back-end" Application

If you have stored all the database object information in your version 1.x application (such as your table structures, forms, reports, queries, macros, and so on) in one database, and all the actual data in another database (a "front-end/back-end" application), use the following procedure to convert these databases to version 2.0.  For this example, your database objects are stored in FRONT.MDB and your data in BACK.MDB.

1	Copy FRONT.MDB and BACK.MDB to a different directory as backups.

2	In the current directory, convert FRONT.MDB to FRONT.NEW.

3	Delete FRONT.MDB and rename FRONT.NEW to FRONT.MDB.

4	Convert BACK.MDB to BACK.NEW.

5	Delete BACK.MDB and rename BACK.NEW to BACK.MDB.

Version 2.0 Setup and the UTILITY.MDA File

Microsoft Access version 2.0 includes an updated UTILITY.MDA file.  If you have modified this library database, you should make a backup copy of this file before installing Microsoft Access version 2.0.  Then modify the version 2.0 copy of the file to include your changes.

Using Visual Basic Version 3.0 Applications

If you or others use a Visual Basic version 3.0 application to access data in your database file, you must upgrade the Visual Basic application before it can use data in a Microsoft Access version 2.0 database.  Wait to convert your Microsoft Access version 1.x database until after you upgrade Visual Basic applications that access it.  You can upgrade a Visual Basic application using the compatibility layer provided with the Microsoft Access Developer's Toolkit, a separate product.  For information on obtaining the Microsoft Access Developer's Toolkit, contact your local reseller or call Microsoft directly at the number for Inside Sales listed in your documentation for the full Microsoft Access.  For information on using the compatibility layer to upgrade your Visual Basic application, see the compatibility layer Readme file (ACC2COMP.TXT) on the Compatibility Layer disk that comes with the Microsoft Access Developer's Toolkit.

Exporting to Version 1.1 Databases

You can export tables from your version 2.0 databases to version 1.1 databases using the Export command on the File menu.  This may be useful if not all users in your organization have upgraded to version 2.0 and you need to downgrade your tables.  Use the same procedure as when exporting to a version 2.0 database.  Note, however, that this applies only to tables; you can't export queries, forms, or other objects to version 1.1 databases.

DefaultValue Property Setting Includes Quotation Marks in Version 2.0

In a version 1.x database, the DefaultValue property setting for a string value does not include quotation marks around the string value.  In a version 2.0 database, the property setting for a string value includes quotation marks.  If you use code or a conditional expression in a version 1.x database to test the value of the DefaultValue property, note that the property will return a different value after you convert your database to version 2.0 format.

For example, if the DefaultValue property of the control City on the Contacts form is set to Paris, in a version 1.x database, this expression is true:

Forms![Contacts]![City].DefaultValue = "Paris"

After converting the database, the preceding expression is no longer true.  Instead, this expression is true:

Forms![Contacts]![City].DefaultValue = """Paris"""

Note that Microsoft Access version 2.0 will correctly run version 1.x applications that contain DefaultValue property string settings that don't include quotation marks.  However, once you convert the application to version 2.0, you will need to modify the DefaultValue property settings.

Owner Access Queries

In Microsoft Access version 2.0, owner access queries can now be used with attached tables (this was not allowed in version 1.x).  If you're creating a secure application, basing your forms and reports on owner access queries lets you give users access to data in the table database, while restricting access to the tables that contain the data.  Users have the same access permissions for an owner access query's underlying tables or queries as the owner of the query.

For example, you can create an owner access query that uses tables in the table database, remove all permissions for the tables from anyone but yourself, and base a form or report on the query.  Users then have no permissions for the tables themselves, but they can open the form and report, or any form or report based on the query, and have your access permissions for the table data while they're using that form or report.

You specify an owner access query by setting the query's RunPermissions property to Owner's or by adding a WITH OWNERACCESS OPTION declaration to the query's SQL statement.

Order of Evaluation of Expressions

The order of evaluation of expressions has changed somewhat in version 2.0 from version 1.x.  It is possible that you may have illegal expressions in your version 1.x application that were not evaluated in version 1.x (because they were never reached), but which will be evaluated in version 2.0 and cause errors.

Applications That Use the SQL Pass-through DLL

If you have a Microsoft Access version 1.x application that uses the SQL Pass-through DLL (MSASP110.DLL), you must convert the application to use the new integrated SQL pass-through functionality in Microsoft Access version 2.0.  The MSASP110.DLL doesn't work with Microsoft Access version 2.0.  Failure to convert such applications can cause unexpected results.

Closing Pop-up Forms and Their Underlying Windows

Pressing Ctrl+F4 will no longer close the underlying window when a pop-up form is active.  To close the window under a pop-up form, you must first close the pop-up form.  Ctrl+F4 will not close a pop-up form.  To close a pop-up form you should use Alt+F4 instead.

Unused Error Messages

The following error messages are no longer used by Microsoft Access.  If you trapped these error message numbers in your Access Basic code, you will need to remove this error message trapping.  The error message numbers that have been removed are 3035, 3038, 3147, 3148, 3149, 3150, 3152, 3153, 3178, 3233, 3236, 3237, and 3255.


Network Installations

Contents

Designating Network Connections

Setting Up Microsoft Access on a Network File Server

Creating Custom Installations for Workstation Users

Designating Network Connections

In the topics in this section, network connections are specified with a logical drive letter, such as N.  If your network supports the use of universal naming convention (UNC) paths of the form \\server\share, you can use a path instead of a logical drive letter.  Setup remembers the paths to the components you install, so if you use logical drive letters to specify network file servers during installation, you have to make those network connections manually and use the same drive letters before you run Setup again.  If you use UNC paths, Setup will make the correct connections automatically.

Setting Up Microsoft Access on a Network File Server

This section is for network administrators who perform an administrator's installation on a network file server or a shared directory.

Users on networks can share the Microsoft Access executable file and files created by Microsoft Access.  Once you've installed Microsoft Access on the network, a workstation user can either install the program and its components on the workstation's hard disk or run Microsoft Access from the network file server.

Workstation users can install Microsoft Access from the file server, instead of from floppy disks.  Alternatively, you can create a script that workstation users can run to install Microsoft Access.  For more information about scripts, see Creating Custom Installations for Workstation Users.

Before you set up Microsoft Access on a network file server, check the following:

The network must be operational, and you must have read, write, and delete privileges for the network directories in which you want to install Microsoft Access.  For more information, see your network software documentation.

Determine if you have enough hard disk space for the type of installation you want.  See Installation Requirements for details.  Setup will alert you if you don't have enough hard disk space.

You must install the Microsoft Windows operating system, version 3.1 or later, on the workstation you use to install Microsoft Access on the network file server, and on any workstations that will run Microsoft Access.  For information about installing Windows, see your Windows documentation.

If any network users share the Windows operating system or other Microsoft applications such as Microsoft Access and Microsoft Word (which share components), they must be logged off the network.  Users must not access the directories that contain shared components on the file server or shared volume [image] for example, W:\WINDOWS and W:\MSAPPS [image] while you are setting up Microsoft Access.  You must have create, write, and delete privileges in these directories.

You should determine which network file server directories the components of Microsoft Access should be installed in.  Setup suggests installing MSACCESS.EXE in the ACCESS directory and installing shared components in the MSAPPS directory of the network file server or the shared volume.  You can specify other paths if you want to.

Setting up Microsoft Access on network workstations is a two-step process.  First, install Microsoft Access on the network file server.  Then set up the workstations, either by installing Microsoft Access on each workstation's hard disk or by setting up the workstations to run Microsoft Access from the file server.

Installation Requirements

If the file server or shared workstation can run Microsoft Windows version 3.1, it can run Microsoft Access, provided that it has sufficient RAM and disk space.  The Microsoft Access program requires 31 megabytes (MB) of available space on the file server or the shared directory.  The shared components of Microsoft Access require 2.5 MB of available space.  Each workstation that will have a complete copy of Microsoft Access must have 23 MB of free hard disk space (or at least 5.5 MB for a minimum installation).  A workstation that runs Microsoft Access from the network requires 3 MB.

To install Microsoft Access on a network file server or a shared directory

1	Ask all users who are sharing Windows or Microsoft applications such as Microsoft Access and Microsoft Word (which share components) to disconnect from the network file server or the shared directory.

2	Start Microsoft Windows, and quit any other applications.

3	Insert the disk labeled "Setup" in drive A.

4	From the File menu in either Program Manager or File Manager, choose Run.

5	Type a:setup /a and then press Enter.  (The /a switch indicates an administrator's installation.)

6	Follow the instructions on the screens that Setup displays.

You will need to supply the network directory in which you want to install the main Microsoft Access program (for example, N:\ACCESS), and the directory for storing shared components, such as GRAPH5.EXE.  Shared components are usually stored in the MSAPPS directory at the same directory level as the directory that contains MSACCESS.EXE [image] for example, if MSACCESS.EXE is stored in N:\ACCESS, then shared components would be stored in N:\MSAPPS.

If you are running the Windows operating system from a shared installation, the proposed location for the shared components is at the same directory level as the shared Windows directory.

Note   To set up Microsoft Access on a network server, you must run Setup /a from floppy disks.  Do not copy the files to a hard disk and run Setup /a from there.  Unless you run Setup /a from floppy disks, Microsoft Access won't be properly configured on the network server, and users won't be able to set up their workstations from the server using Setup.

When users install Microsoft Access on their workstations by running Setup from this administrator's installation, the shared components can be installed on the user's workstation or run from the network.  Before you complete the administrator's installation, decide if the shared components will be automatically installed on individual workstations, automatically shared from the network, or if the choice will be left to the workstation user.

Tip   After you set up Microsoft Access on a network server, you should make the program directory read-only so that users can't delete the files.

Note   The SYSTEM.MDA file, the sample database files, and the files for the Microsoft Access Wizards must not be in a read-only directory.  Microsoft Access Setup automatically puts the SYSTEM.MDA and Wizard files in a subdirectory of the Microsoft Access program directory called WORKDIR.  So, for example, if your Microsoft Access program directory is N:\ACCESS, the SYSTEM.MDA and Wizard files will be installed in the N:\ACCESS\WORKDIR directory.  Make sure that this directory is not read-only.  You can use this directory for any shared Microsoft Access files that must be updatable.

You must create a shared SYSTEM.MDA file for each Microsoft Access workgroup in your system.  If you need more than one SYSTEM.MDA file, you should also put them in the WORKDIR subdirectory.  For details on creating and maintaining Microsoft Access workgroups, see Chapter 14, "Securing Your Application," in Microsoft Access Building Applications.

If your operating system does not allow you to have a single read/write subdirectory of a read-only share directory (for example, Windows for Workgroups has this restriction), make the Microsoft Access program directory read/write, but make all the files in the Microsoft Access program directory and its subdirectories (except for the WORKDIR subdirectory) read-only.

Creating Custom Installations for Workstation Users

You can create scripts to run Setup "automatically" (that is, so Setup doesn't take input from the user) and control how Setup installs Microsoft Access.  With a script, you can:

Perform a complete installation automatically.

Control which type of installation [image] Typical, Complete/Custom, Laptop (Minimum), or Workstation [image] you want Setup to perform.

Specify the directory in which to install Microsoft Access.

Ensure that all installations in a workgroup are the same.

Setup uses information in the file SETUP.STF to determine which files to install and where they should be copied.

To perform a complete installation automatically, just add the /q switch when you run Setup.  At the command prompt, type the path to the server or directory where Setup is installed, and then type setup /q to start an automatic installation.  When you use this switch, Setup reads information from SETUP.STF and installs Microsoft Access in the program directory for the previous version of Microsoft Access or in the default Microsoft Access program directory, C:\ACCESS, without prompting the user for information.

Tip   If you run Setup with the /q switch, Microsoft Access Setup will still display the last dialog box in Setup (telling you that Setup was or was not completed).  If you don't want to see any Setup dialog boxes, including this one, use the /q1 switch.

To control which type of installation Setup performs and specify the directory in which Microsoft Access is installed, edit SETUP.STF to create a custom script that workstation users can run to install Microsoft Access.  (This procedure is only for an administrator's installation of Microsoft Access on a network file server or a shared directory, so run Setup using the setup /a command before you edit the SETUP.STF file.)

Note   A table of Microsoft Access components, their recommended locations for network and workstation installations, and explanatory notes is provided in Files Included with Microsoft Access.

Editing SETUP.STF to Create a Script

This section describes how to create a script that automatically performs a Typical, Complete/Custom, Laptop (Minimum), or Workstation installation and how to specify a directory where Setup will install Microsoft Access.

To edit the information in SETUP.STF

1	Copy the SETUP.STF file from the directory in which you installed the main Microsoft Access program and give the file a new name.  Open the copy of SETUP.STF (not the original) with any spreadsheet application, word processor, or text editor.  It's easiest to work with the file in a spreadsheet application, such as Microsoft Excel, because the file is in the form of a spreadsheet table.

2	To specify the type of installation you want the script to perform, scroll through the table until you see the following list of installation options in the "Title" column (the third column).  These options are listed under the heading "==== Main Dialog Options ===="; each option has an ampersand (&) before it:

Typical
Complete/Custom
Laptop (Minimum)
Workstation

One of these options has a "yes" next to it in the "Install During Batch Mode" column (the second column, just to the left of the "Title" column).  The other three options have a "no" in this column.  To change which installation type you want the script to perform by default, type yes in the "Install During Batch Mode" column in the same row as this option.  Type no next to all the other options.  Note that only one of the four installation types can be set to "yes," while the others must be "no."

3	If you want the script to perform a Complete/Custom installation (you chose Complete/Custom in step 2), scroll down until you see the "==== Custom Options ====" heading in the "Title" column (the third column).  Listed under this heading are all the custom options.  Each of these options is set to "yes" by default (all the custom options will be installed).  To choose whether a custom option is installed by default or not, type yes or no in the "Install During Batch Mode" column (the second column) to the left of this option.

If the value in the "Object Type" column (the fifth column) is "OptionDlg," the custom option has suboptions.  The suboptions are listed after the main option.  (The "Object Data" column in the main option's row lists the row numbers of the suboptions for this option.)  To install only some of the suboptions, you must leave the main option set to "yes" in the "Install During Batch Mode" column and change the setting of each individual suboption in the "Install During Batch Mode" column.

4	To specify a directory where Setup will install Microsoft Access, find the first numbered row, with "Microsoft Access" in the "Title" column.  In the "Object Data" column in this row, replace "C:\ACCESS" with the name of the directory where you want to install Microsoft Access.

Important   To ensure that Setup works properly, do not edit any other part of the file.  If the initial value in a cell is empty, do not add anything to the cell.  If you are using a text editor, do not delete Tab characters that separate table columns.

5	Save the edited file in text-only format with the new name you assigned in step 1.

Distributing and Using a Script

After you create a script, you can copy it to the file server or shared volume from which you want users to install Microsoft Access, or you can distribute it with Microsoft Mail or another application that can send items across a network.

Use one of the following methods to distribute a script:

Copy SETUP.EXE and give the copy the same file name you gave the script but use the .EXE file name extension.  For example, if you named the script NEWSETUP.STF, name the copy of Setup NEWSETUP.EXE.  Put the renamed setup file and the script on the file server or the shared volume.  Direct your users to run the copy of Setup (for example, NEWSETUP.EXE, not SETUP.EXE).  Use this method if only certain users want to use this custom script.

To create one script for all users, rename the SETUP.STF file that comes with Microsoft Access to something else, such as SETUP.OLD.  Name the copy of the script that you edited SETUP.STF, and save it in the same network directory as SETUP.EXE.  Direct your users to run SETUP.EXE from the file server or the shared volume.

To create different installation scripts for different groups of users, distribute the script with Microsoft Mail or another application as a Program Manager icon.  The command line specifies the script and switches, as shown in the following table.

Switch	Instructions

/t scriptname	Substitute the name of the new script for scriptname.

/n username	(Optional) Substitute a value for username to prevent Setup from prompting the user for a name.  The name must be enclosed in quotation marks as shown in the example that follows.  To automatically register the workstation copy of Microsoft Access with the workstation's existing user name, type the quotation marks with no name ("").  Setup uses the name specified in the WIN.INI file on the workstation in the DefName line of the [MS User Info] section.

/q	Causes Setup to run without any user interaction.

For example, suppose you install Microsoft Access in the ACCESS directory of a file server (where X designates the file server) and distribute a script for automatic installation that uses the MYSCRIPT.STF script file to a user named Paul Tanner.  The command line to run the script would be:

x:\access\setup.exe /t myscript.stf /n "Paul Tanner" /q

To distribute a script with Microsoft Mail

1	Create a new message and then choose Insert Object from the Edit menu in Microsoft Mail.

2	In the Object Type box, select Package, and then choose the OK button.

3	From the Edit menu in Object Packager, choose Command Line.

4	Type the full path to SETUP.EXE in the ACCESS directory of the file server or the shared directory.  (If your network supports UNC pathnames, use that syntax.  If not, users will need to make the network connection themselves by using the same drive letter you specified before running Setup.)  Type setup and the switches and arguments as needed, and then choose the OK button.

5	To attach the Microsoft Access Setup icon to the command line, choose the Insert Icon button in Object Packager.

6	Choose the Browse button to locate SETUP.EXE in the ACCESS directory of the network file server, and then choose the OK button.

7	Choose Update from the File menu to add the icon to the Mail message, and then choose Exit from the File menu to close Object Packager.

The icon is now ready to distribute.  Anyone who receives the message can double-click the icon to run Setup from the network and install Microsoft Access by using the script you specified with the /t switch.


Documentation Updates

Contents

Book: Microsoft Access Getting Started

Book: Microsoft Access User's Guide

Book: Microsoft Access Building Applications

Help: Microsoft Access Help

The following errors in printed documentation were discovered after the books were printed.  Please mark the changes in your copies of the books.  We apologize for any inconvenience.

Book: Microsoft Access Getting Started

Page: 18

Chapter: 2, "Microsoft Access Basics"

In the second bullet under "Microsoft Access Requirements," change "19 megabytes" to "21.5 megabytes."

Book: Microsoft Access User's Guide

Page: 2

Chapter: 1, "Setting Up Microsoft Access"

The disk space requirements for the Microsoft Setup options are as follows:

Minimum	5.5 megabytes (MB)

Typical	21.5 MB

Complete/Custom	23 MB

Pages: 11-18

Chapter: 1, "Setting Up Microsoft Access"

All of the conversion issues covered in this section that apply to validation rules also apply to default value expressions.  Only validation rules are mentioned in the book.

Page: 17

Chapter: 1, "Setting Up Microsoft Access"

Add a new bullet to the bulleted list on this page:

The User (now named CurrentUser) and Eval functions.  (The Microsoft Access version 1.x User function is renamed CurrentUser in Microsoft Access version 2.0.)

Page: 152

Chapter: 8, "Changing and Customizing Tables"

In the "Deciding Which Fields to Index" section, change the second paragraph, first sentence from:

The primary key of a table is automatically indexed, and you can't index a field whose data type is Memo or Counter.

to:

The primary key of a table is automatically indexed, and you can't index a field whose data type is Memo or OLE Object.

Page: 384

Chapter: 16, "Customizing Forms"

In the tip in the "Displaying Rows from a Table or Query" section, the OnReposition property should be changed to the OnCurrent property.

Book: Microsoft Access Building Applications

Page: 86

Chapter: 4, "Using Forms to Collect, Display, and Filter Information"

Insert this note after the code example:

Note   In a subform's module, use Me to refer to controls on the subform, and use Me.Parent to refer to controls on the main form.  This enables Access Basic to resolve the references when the form is in Design view as well as Form view.  Without the Me property, Access Basic can resolve the references in Form view, so your code works while the user is using the form; however, you can't compile the module while the form is in Design view.  To be able to compile the module while you're working in Design view, use the Me property in your references.

Page: 120

Chapter: 5, "Access Basic Fundamentals"

Add the following note to the section "Public and Private Procedures":

Note   Because procedures in a form or report module are private to the form or report, and Access Basic functions are evaluated at the module level, you can't use a form or report module function call as an argument to an Access Basic function.

For example, the following function call on the MyForm form will produce an "Invalid reference to field TypeDescription" error if the MyFunc function is in the MyForm form's module:

Sum(MyFunc())

To use a user-defined function call as an argument to an Access Basic function, make sure the function is in a global module.  In this example, you could move the MyFunc function to a global module.

Page: 177

Chapter: 7, "Objects and Collections"

Replace the first two paragraphs and code example on this page with the following:

When you work with data access objects, you can use default collections as a shortcut to avoid typing long object identifiers.  However, it's often easiest to see the relationship between objects if you use object variables to represent them, or use their full identifiers.  For example, you can refer to the current database in either of the following ways:

DBEngine.Workspaces(0).Databases(0)
DBEngine(0)(0)

The first example refers to the current database by identifying it as the first (zero) element of the Databases collection, which is, in turn, contained by the first (zero) element of the Workspaces collection (the current workspace).  Because Workspaces and Databases are default collections of the objects that contain them, the second example refers to the current database without explicitly naming the collections.  In this syntax, there are no .(dot) operators between the indexes of the default collections.

Page: 197

Chapter: 8, "Events"

In the table in the "Focus Events" section, add the following sentence to the first row (Activate), second column (Occurs):

The Activate event does not occur when focus moves to a pop-up form.

Page: 201

Chapter: 8, "Events"

The first row of the table in the "Error and Timing Events" section says you can cancel error events.  However, Error event procedures have no Cancel argument, and you can't cancel an Error event using the CancelEvent action in a macro.  Instead, setting the Response argument to DATA_ERRCONTINUE in an Error event procedure ignores the error, which is functionally similar to canceling the event.

Page: 245

Chapter: 11, "Working With Sets of Records"

Replace the second bullet in the bulleted list near the top of the page with the following two bullets:

For a Recordset object created from a QueryDef or attached TableDef object, DB_OPEN_DYNASET is the default type.

For a Recordset object created from a Database object, DB_OPEN_TABLE is the default type if the object can be opened as a table.  Otherwise, the default type is DB_OPEN_DYNASET.

Page: 245

Chapter: 11, "Working With Sets of Records"

Replace the text and code example that follows the first code example in the section, "Creating a Recordset Variable for a Local Table-type Recordset," with the following:

Note that using the DB_OPEN_TABLE constant ensures that the OpenRecordset method creates a table-type recordset.  However, you could omit the type in this example because table is the default type for a recordset that can be opened as a table.  To create a dynaset, you must use the DB_OPEN_DYNASET constant, as in the following example:

Dim MyDb As Database, MySet As Recordset

Set MyDb = DBEngine.Workspaces(0).Databases(0)
Set MyRs = MyDb.OpenRecordset("Customers", DB_OPEN_DYNASET)

Page: 246

Chapter: 11, "Working With Sets of Records"

Replace the code lines that begin "Set MyDb" in the code examples in the section, "Creating a Recordset Variable Based on a Query," with the following:

Set MyDb = DBEngine.Workspaces(0).Databases(0)

Pages: 248-249

Chapter: 11, "Working With Sets of Records"

Replace the code line that begins "Set MySet" in the first code example in the section, "Sorting with a New Recordset," with the following:

Set MySet = MyDb.OpenRecordset("Orders", DB_OPEN_DYNASET)

Replace the first code line that begins "Set MySet" in the fourth code example in the same section with the following:

Set MySet = MyDb.OpenRecordset("Employees", DB_OPEN_DYNASET)

Replace the code line that begins "Set MySet" in the first code example in the section, "Filtering a Recordset," with the following:

Set MySet = MyDb.OpenRecordset("Orders", DB_OPEN_DYNASET)

Pages: 256-257

Chapter: 11, "Working With Sets of Records"

Replace the code line that begins "Set MySet" in the first code example in the section, "Using the Find Methods," with the following:

Set MySet = MyDb.OpenRecordset("Employees", DB_OPEN_DYNASET)

Replace the code line that begins "Set MySet" in the second code example in the same section with the following:

Set MySet = MyDb.OpenRecordset("Customers", DB_OPEN_DYNASET)

Page: 287

Chapter: 13, "Communicating With Other Applications"

The introductory paragraph to the last code example in the section "Creating an OLE Automation Object Using the CreateObject Function" should be revised.

Old text:

For example, the following code creates a worksheet called Budget, inserts a text file and a value from a Microsoft Access database, saves the worksheet, and closes the application.

Revised text:

For example, the following code creates a worksheet, inserts a value from a Microsoft Access database into a cell, saves the worksheet, and closes the application.

Page 347

Chapter: 15, "Using Library Databases and Dynamic-Link Libraries"

Insert this note before the sidebar "Avoiding Conflicts with the Current Database":

Note   Make sure to compile and save all Access Basic modules in your library database, including form and report modules, before distributing your application.  Users may encounter unexpected errors in library database modules that haven't been compiled and saved.

Page: 351

Chapter: 15, "Using Library Databases and Dynamic-Link Libraries"

Add these two sentences to the end of the second paragraph under "Running Macros and Actions in a Library Database":

One exception to this rule occurs when you use the RunMacro action to call a macro in a library database.  In that case, Microsoft Access looks for the macro in the library database, and does not look for it in the current database.

Page: 355

Chapter: 15, "Using Library Databases and Dynamic-Link Libraries"

Replace the syntax used to install a table or query Wizard add-in with this:

displayname=functionname [,,statustext]

Replace the text between the two notes with this:

To add status text to the list of Wizards you can choose from when the Wizard is selected, specify the text after the name of the function.  Note that you must use curly brackets ({ }) to delimit the status text.  Precede the text with two commas; the first comma acts as a placeholder.  For example, to install a table Wizard that displays the Wizard name My Table Wizard, calls the function MyTableWiz_Entry, and displays status text, add this entry:

[Table Wizards]
My Table Wizard=MyTableWiz_Entry,, {This Wizard creates a new table}

The next time you run Microsoft Access, the entry My Table Wizard appears in the list of Table Wizards you can choose from when creating a new table, and the status text "This Wizard creates a new table" is displayed.

Replace the syntax used to install a form or report Wizard add-in with this:

displayname=functionname[,[wizardid][,statustext]]

Page: 356

Chapter: 15, "Using Library Databases and Dynamic-Link Libraries"

Add this text after the first note and before the procedure on installing a property builder or Wizard add-in:

To add status text to the list of Wizards that you can choose from when the Wizard is selected, specify the text after the Integer argument or its placeholder.  If you don't specify an Integer argument, you must still type a comma as a placeholder.  Note that you must use curly brackets ({ }) to delimit the status text.  For example, to install a form Wizard that displays the Wizard name My Form Wizard, calls the function MyFormWiz_Entry, and displays status text, add this entry:

[Form Wizards]
My Form Wizard=MyFormWiz_Entry,, {This Wizard creates a new form}

The following errors in online Help were discovered after the Help file was finalized.

Help: Microsoft Access Help

ColumnHidden Property

In the first sentence in the Setting section, Long should be changed to Boolean.

In the second line of the ShowColumn Sub procedure in the example, DB_LONG should be changed to DB_BOOLEAN.

ColumnOrder Property

In the first sentence in the Setting section, Long should be changed to Integer.

In the fourth and fifth lines of the first example, DB_LONG should be changed to DB_INTEGER.

Creating a Subform

Add the following note to this topic:

Note   If you requery a calculated field in a master form, all of the fields in the master form are considered dirty.  Thus the embedded subform requeries because its dependent field is dirty.  This does not apply to any field in an embedded subform, since none of the fields on which it depends will be affected.

Customizing MSACC20.INI Settings

The Note at the end of the "To specify a library database to be loaded at startup" procedure in the library databases section of this topic should read as follows:

Note   Library modules aren't available for editing by Microsoft Access users by default, but you can make them available for editing by adding the setting DebugLibraries=True to the [Options] section of MSACC20.INI.

Database Object, Databases Collection

Add the following paragraphs to this topic:

A variable declared as a Database object in a Sub or Function procedure by default exists only while the procedure is executing.  As a result, references to any data access objects in the database are invalid after the procedure stops executing, even if they're represented by global variables.  For example, if you declare a Recordset variable MyRs as a global variable, and then execute the following procedure, MyRs is invalid after the procedure stops executing:

Sub TestRecordset()

Dim MyDb As Database

Set MyDb = DBEngine.Workspaces(0).Databases(0)
Set MyRs = MyDb.OpenRecordset("Categories")

End Sub

To avoid this problem, declare the Database variable as a global variable or use the Static reserved word in the declaration.  For example, you could revise the preceding procedure as follows:

Sub TestRecordset()

Dim MyDb As Static Database

Set MyDb = DBEngine.Workspaces(0).Databases(0)
Set MyRs = MyDb.OpenRecordset("Categories")

End Sub

Database Object, Databases Collection

Add the following note to this topic:

Important   To refer to a database's properties, methods, or objects, you must first declare and set a variable to represent the database.  For example, to refer to the Name property of the current database, you must first assign the current database to a variable:

Dim MyDb as Database

Set MyDb = DBEngine.Workspaces(0).Databases(0)

' Display the name of the current database in the Immediate window.
Debug.Print MyDb.Name

Microsoft Access produces an error if you refer to a database property, method, or object without first declaring and setting a variable to represent the database.  For example, the following code produces an error:

Debug.Print DBEngine.Workspaces(0).Databases(0).Name

DefaultValue Property

Add the following paragraph to this topic:

In an Access Basic procedure, if you're setting the DefaultValue property to a text value, you must enclose the text in three pairs of double quotation marks (").  For example, type the following code line to set the default value of the MyField field to "Paris":

MyField.DefaultValue = """Paris"""

Microsoft Access displays the error value #Name? if you enclose the default value text value in only one pair of double quotation marks.

Dirty Property

The sentence in the Usage section should be modified to read:

This property setting is read-only in Form view and Datasheet view, and isn't available in Design view or on unbound forms.

DistinctCount Property

This property was added to Microsoft Access too late for its Help topic to be included in the main Help file.  Click the following property name to view a description of the property:

DistinctCount Property

Embedding a Graph That Displays Data from Microsoft Access

Add the following note to this topic:

Note  If your form includes an embedded or linked graph created with Microsoft Graph, and you don't want users to edit the graph in Form view, set the graph's Enabled property to No.  This is recommended because you can't lock a graph by setting its Locked property to Yes.  (If you do set a graph's Locked and Enabled properties to Yes, you'll be able to make changes to the graph in Form view, but you won't be able to save the changes.)

OLE applications other than Microsoft Graph may also have this same behavior.

Embedding a Graph That Displays Data from Other Applications

Add the following note to this topic:

Note  If your form includes an embedded or linked graph created with Microsoft Graph, and you don't want users to edit the graph in Form view, set the graph's Enabled property to No.  This is recommended because you can't lock a graph by setting its Locked property to Yes.  (If you do set a graph's Locked and Enabled properties to Yes, you'll be able to make changes to the graph in Form view, but you won't be able to save the changes.)

OLE applications other than Microsoft Graph may also have this same behavior.

Enabled, Locked Properties

Add the following note to this topic:

Note  If your form includes an embedded or linked graph created with Microsoft Graph, and you don't want users to edit the graph in Form view, set the graph's Enabled property to No.  This is recommended because you can't lock a graph by setting its Locked property to Yes.  (If you do set a graph's Locked and Enabled properties to Yes, you'll be able to make changes to the graph in Form view, but you won't be able to save the changes.)

OLE applications other than Microsoft Graph may also have this same behavior.

Execute Method

The Syntax section of this topic should be revised as follows:

Syntax

Database: database.Execute source [, options]

QueryDef: querydef.Execute [options]

The last line in the Example:

MyDB.Execute (MyQuery.Name)	' Run query.

should be changed to:

MyDB.Execute MyQuery.Name	' Run query.

This example will work as originally shown, because you can use parentheses around an argument if there's only one argument, but this is not recommended.

Height, Width Properties

Add the following section to this topic:

Usage

For sections, the Height property setting is read-only in Print Preview and when the section is being printed.

Import Database Command (File Menu - Add-Ins Submenu)

Add the following note to the end of this topic:

Note   You can't import or export custom toolbars with a database.  The Import Database command will not transfer custom toolbars.

IsolateODBCTrans Property

This property was added to Microsoft Access too late for its Help topic to be included in the main Help file.  Click the following property name to view a description of the property:

IsolateODBCTrans Property

Keyboard Events (KeyDown, KeyUp, KeyPress)

Keyboard events don't occur for a key or key combination if the key or key combination is assigned an action or set of actions in the AutoKeys macro.  In addition, some keys and key combinations to which Microsoft Access assigns a particular action in certain instances (for example, Shift+F2, which is used to open the Zoom window), do not trigger keyboard events in those instances.  These key and key combinations are:

Alt+Backspace	Ctrl+F2	Ctrl+F4 (whenever a pop-up form isn't active)
Ctrl+Ins	Ctrl+Tab	Ctrl+A
Ctrl+C	Ctrl+F	Ctrl+H
Ctrl+N	Ctrl+O	Ctrl+P
Ctrl+S	Ctrl+V	Ctrl+X
Ctrl+Z	Del	F1
Shift+F1	Shift+F2	Shift+Ctrl+Tab
Shift+Del	Shift+Ins
In addition, the following keys and key combinations don't trigger keyboard events when Access Basic code or a macro are running:

Alt+F1	Alt+F2	Alt+Shift+F2
Ctrl+Alt+F1	Ctrl+F11	F11
F12	Shift+F12
Note that these keys and key combinations don't trigger keyboard events only in those instances when Microsoft Access assigns an action to the key or key combination.  For example, the Ctrl+X key combination is used to cut text selected in a field or control.  If you press Ctrl+X in such an instance, the keyboard events aren't triggered.  However, if you don't have text selected (for example, the focus is not in a field or control), pressing this key combination will trigger the keyboard events.

Label Control

Add the following note to this topic:

Note   Labels that are attached to another control, such as a text box, do not receive the Click, DblClick, MouseDown, MouseMove, or MouseUp events.

Mouse Events: Click Event; DblClick Event; MouseDown, MouseUp Events; MouseMove Event

Add the following note to these topics:

Note   Labels that are attached to another control, such as a text box, do not receive this event.

Permissions Property

Insert this note at the end of the topic:

Note   Microsoft Access stores permission settings as long integers.  Make sure you use the Long (long integer) data type when you declare functions that return permission settings or variables that will be used to store permission settings.

Recordset Object, Recordsets Collection

Add the following note to this topic:

Note   If you use variables to represent a Recordset object and the Database object that contains the recordset, make sure the variables have the same scope or lifetime.  For example, if you declare a global Recordset variable, make sure the variable that represents the database that contains the recordset is also global, or is declared in a Sub or Function procedure using the Static reserved word.

Referring to Controls on a Subform or Subreport

Insert this note at the end of the topic:

Note   In a subform's module, use Me to refer to controls on the subform, and use Me.Parent to refer to controls on the main form.  This enables Access Basic to resolve the references when the form is in Design view as well as Form view.  Without the Me property, Access Basic can resolve the references in Form view, so your code works while the user is using the form; however, you can't compile the module while the form is in Design view.  To be able to compile the module while you're working in Design view, use the Me property in your references.  For example, this expression refers to the Unit Price control on a subform from the subform's module: Me![Unit Price].

Refresh Method (Data Access)

Add the following note to this topic:

Note   Changes to data access objects made through the Microsoft Access user interface may not be immediately represented in the object or collection.  If you make a change in the Database window, it will not be reflected in the corresponding collection unless you use the Refresh method on the collection containing that object.

For example, if you delete a table from the Database window, you will need to execute the following line of Access Basic code to remove the table from the TableDefs collection (assuming an existing Database object MyDatabase):

MyDatabase.TableDefs.Refresh

It is also true that when you make a change to a data access object or collection with code, it may not be reflected in the Microsoft Access user interface until the interface is refreshed.  For example, if you delete a table in a TableDefs collection using code, it may still appear in the Database window until you click another object type and then click Tables again.

Requery Method

Add the following note to this topic:

Note   If you requery a calculated field in a master form, all of the fields in the master form are considered dirty.  Thus the embedded subform requeries because its dependent field is dirty.  This does not apply to any field in an embedded subform, since none of the fields on which it depends will be affected.

RowHeight Property

In the first sentence in the Setting section, Long should be changed to Integer.

In the fourth line of the first example, DB_LONG should be changed to DB_INTEGER.

Updated Event, OnUpdated Property

This event and its associated event property apply to graph controls as well as unbound and bound object frames on a form.

User Object, Users Collection

Add the following note to this topic:

Note   If you're using a Microsoft Access version 1.x system database, you can't refer to User objects in a Group object's Users collection, or append to that collection.  However, you can refer to User objects in a Workspace object's Users collection, and append to that Users collection.  You can also refer to Group objects in a User object's Groups collection, and append to that collection.

Using a Calculated Field in a Query

Add the following note to this topic:

Note   If you requery a calculated field in a master form, all of the fields in the master form are considered dirty.  Thus the embedded subform requeries because its dependent field is dirty.  This does not apply to any field in an embedded subform, since none of the fields on which it depends will be affected.

Using AutoLookup

In Microsoft Access version 2.0, AutoLookup is not supported for tables that have a one-to-one relationship.  Delete the text after "one-to-many relationship" so that the second paragraph of this topic reads:

To use AutoLookup, you must be working with tables that have a one-to-many relationship.

Also, delete the note at the end of this topic.

ValidationRule, ValidationText Properties

The first paragraph of the Setting section says the maximum length for each property is 255 characters.  The maximum length for the ValidationText property is 255 characters, but the maximum length for the ValidationRule property is 2048 characters.

WindowHeight, WindowWidth Properties

These properties apply to reports as well as to forms.

Year Function

The Syntax section should read:

Year(dateexpression)

Delete the paragraphs in the Remarks section describing the firstweekday and firstweek arguments (these arguments are not supported by the Year function).

The final sentence in the topic should read:

If dateexpression is Null, this function returns a Null.


Using Microsoft Access Version 2.0 with Other Software

Contents

Microsoft Visual Basic

Accessing Microsoft Access Data from Microsoft Word and Microsoft Excel

Using Microsoft Access with Paradox Databases

Running Multiple Data Access Applications

Using Microsoft Access to Import, Attach, or Export to Microsoft FoxPro Version 2.5 Files

Lotus cc:Mail or Lotus Notes

Using Microsoft Access with Microsoft Video for Windows

Windows NT

Setting Up Microsoft Access on a Novell Network

Using Microsoft Access on Novell NetWare Servers and Banyan VINES Servers (Increasing the Number of Record Locks)

Using Microsoft Access with Microsoft LAN Manager

Using Microsoft Access with Microsoft Windows for Workgroups

Using SQL Server Data Installed on a Novell NetWare LAN or a Banyan VINES Network

Asynchronous Query Execution and ODBC Drivers

ORACLE Server Databases and Null Indexes

Microsoft Visual Basic

Microsoft Access version 2.0 contains a later version of the Microsoft Jet database engine than Microsoft Visual Basic 3.0 does.  Thus, you will not be able to use Microsoft Access version 2.0 databases with Microsoft Visual Basic version 3.0 until you upgrade your Visual Basic application.  For more information, see Using Visual Basic 3.0 Applications.

Accessing Microsoft Access Data from Microsoft Word and Microsoft Excel

Microsoft Access 2.0 ships with a driver to allow other Microsoft Office applications to manipulate Access 2.0 data.  When you do a Custom or Maintenance setup of Microsoft Access, or when you do a Typical setup and the Microsoft Access Setup program finds an earlier driver used to access Microsoft Access data, the Microsoft Access 2.0 ODBC Driver for Microsoft Office is installed on your hard disk.  You can use this driver to access and manipulate Microsoft Access 2.0 data from Microsoft Word or Microsoft Excel.  However, this driver is certified to work only with Microsoft Word and Microsoft Excel; do not use this driver to access Microsoft Access data from other ODBC client applications.

Also, don't use this driver to access Microsoft Access data from Microsoft Access.  Microsoft Access has a built-in driver for this task.

To use this new driver with Microsoft Word version 6.0, use Word's mail merge feature.  When Word displays the Open Data Source dialog box, make certain that the Confirm Conversions check box is selected.  Then select "MS Access 2.0 Databases via ODBC (*.mdb)" as a data source.

To use this new driver with Microsoft Excel version 5.0, choose the Get External Data command from the Data menu.  This activates the Microsoft Query feature.  Choose the Other button in the Select Data Source dialog box.  Then select "MS Access 2.0 Databases" as the data source in the ODBC Data Sources dialog box.

Here are some additional tips about using the Microsoft Access 2.0 ODBC Driver for Microsoft Office:

If you have a database that is in a directory that contains an underscore ("_") in its name, you won't be able to open this database from Microsoft Word and Microsoft Excel using the Microsoft Access 2.0 ODBC Driver for Microsoft Office.  You must first rename the directory or move the database to a directory that doesn't have an underscore in the name.

When using Microsoft Query and the Microsoft Access 2.0 ODBC Driver for Microsoft Office, you can't update a row where there is a text column that contains 255 characters of data.

When deleting records using Microsoft Query and the Microsoft Access 2.0 ODBC Driver for MS Office, you may cause related records to be deleted.  Due to the cascading delete functionality of the Microsoft Jet 2.0 database engine, deleting one record from a table may cause related records in other tables to be deleted as well.  The deletion of related records will occur without warning to the user.

Using Microsoft Access with Paradox Databases

The following tips and instructions will help you use Microsoft Access version 2.0 with Paradox and Paradox for Windows databases.

Selecting the Paradox Locking Style

You can use the Paradox 4.X locking style to access both Paradox 3.X and 4.X tables.  You can't attach Paradox 4.X tables while using the Paradox 3.X locking style.

Note, however, that if a Paradox 3.5 user opens a table, you won't be able to open or import from this table using the 4.X locking style.  The table will be inaccessible from Microsoft Access until the Paradox 3.5 user closes it.

For information on how to set a Paradox locking style, search Microsoft Access Help for "customizing Microsoft Access" and read the section of the "Customizing MSACC20.INI Settings" Help topic on settings used for interaction with Paradox databases.

Paradox Tables on a Read-only Drive

You cannot attach or import from Paradox tables on read-only drives.  This is because Microsoft Access cannot create the necessary lock files.

Attaching Nonkeyed Paradox Tables

If you attach an empty Paradox table with no primary key, you will be able to add records the first time you use the table.  However, since Microsoft Access can't update Paradox tables without primary keys, once the table is closed and reopened, it will be read-only.

Note that you can open only one cursor at a time on a nonkeyed Paradox table.

ParadoxNetPaths Must Be Identical

In Microsoft Access, the ParadoxNetPath parameter in the MSACC20.INI file must refer to the same path, including the drive letter, for all users sharing the same database.  That is, all users sharing the same data must have the same ParadoxNetPath entry.  This parameter is located in the [Paradox ISAM] section of the .INI file.

In Paradox, you can do this either by running nupdate or by issuing the -net parameter (Paradox 4.X versions only) at the DOS prompt.  If you use the -net parameter, be sure to include the "\" at the end of the path.  This is because both Microsoft Access and the Paradox nupdate program place the "\" at the end automatically.  The -net parameter was not available in Paradox prior to version 4.0.

Paradox .LCK File Issues

Occasionally the Paradox .LCK file will be inadvertently left in a directory.  This will prevent either Microsoft Access or Paradox from accessing files in that directory.  To remedy this situation, you should delete the .LCK file.

Potential Paradox for Windows Restructure Problem

Problems occasionally occur when using the Paradox for Windows table restructure routine.  If you are having difficulty getting Microsoft Access to open your Paradox 4.X table properly, consider restructuring it in Paradox for DOS version 4.0 or 4.5 and trying again.

CONFIG.SYS FILES Setting When Accessing Paradox Data

Using Microsoft Access to attach Paradox tables when the FILES setting in your CONFIG.SYS file is low (below 40) can cause Microsoft Access problems.  This is especially true if you are attaching several Paradox tables with multiple secondary indexes.  Make sure the FILES setting in your CONFIG.SYS file is high enough.  In general you should have enough files to accommodate the following:

Two files for each Paradox table you plan to attach.

One file for each Paradox table with a primary index.

Two files for each secondary index.

If the Paradox 3.X locking style is used, you'll need one file for each .LCK file and one file for each directory containing Paradox files that will be accessed simultaneously.

If the Paradox 4.X locking style is used, then add two files for each directory containing Paradox files that will be accessed simultaneously.

Paradox Multiuser Issues

Microsoft Access version 2.0 is unable to attach or open Paradox tables in the private directory of an active Paradox session.

While you have an attached Paradox table open in Microsoft Access, records added by other users will not be visible to you until you close and reopen the table.  However, records added by you in Microsoft Access will be visible to the Paradox user according to their "refresh" setting.

Paradox Exporting Issues

If you attempt to export a Microsoft Access table containing long field names to Paradox, and the first 25 characters are identical to an existing field name, Microsoft Access will generate a unique field name.

When Microsoft Access exports a table with a field name containing a "#" it is converted to "." (period).  The parenthesis, curly bracket, and double quote (that is, (  ), {  }, and ") characters are all converted to "_" (an underscore).

Exporting Microsoft Access Memo fields to Paradox format results in extra carriage return characters.

When using Access Basic to create Paradox tables, text columns will default to 255 characters if you do not specify a field width using the FieldSize property.  Wide columns such as these make it easy for the new table to exceed the 1350 character maximum width of a Paradox table with a primary key.  If you attempt to append a primary index to a Paradox table wider than 1350 characters, you will get an error message.

Primary Key Greater Than 255 Bytes

If a multifield primary key is greater than 255 bytes, the table can only be opened read-only.  f you have a table with a two-plus field primary index, and the sum of the bytes used by the index exceeds 255 bytes (characters), you are limited to read-only access to the table.

Encrypted Tables

Microsoft Access doesn't support auxiliary passwords on Paradox tables.

Paradox Referential Integrity

Microsoft Access referential integrity doesn't work with attached Paradox tables.  Attached Paradox tables can't be used to trigger cascading deletes or updates, or prevent orphaning of records (deleting a master record when related detail records still exist in other tables).

Specifying a User Name in the ParadoxUserName Entry in the MSACC20.INI File

You must specify a user name in the ParadoxUserName entry in the [Paradox ISAM] section in your MSACC20.INI file.  There must also not be more than one user on a network registered with the same name.

This problem can occur if you ran Microsoft Access Setup, but didn't specify a name when prompted, or if you ran Setup with the /q option and didn't specify a name using the /n username option.  In these cases, Setup uses the company name in the ParadoxUserName entry.  This works fine for a single user, but on a network, if more than one person does this, there will be duplicate names.

To fix this problem, make sure you specify a user name when you set up Microsoft Access, or use the /n option when you set up using setup /q.  If you've already run Setup, edit the ParadoxUserName entry manually and add a user name.

Running Multiple Data Access Applications

Microsoft Access, Microsoft Access custom applications, Microsoft Visual Basic version 3.0, and Visual Basic custom applications all use the same database engine to perform their database-related operations.  If one or more of these are running simultaneously, you must be sure that all sections and entries from the initialization (.INI) file that are used for data manipulation (the entries in the [Installable ISAMs], [Paradox ISAM], [dBASE ISAM], and [Btrieve ISAM] sections) are included in the initialization file for each application.  This ensures that you can use data in other formats or applications, such as FoxPro, dBASE, Paradox, or Btrieve.

If two or more applications that use the database engine are running simultaneously, the engine is initialized to the .INI file settings of the application that was started first.

If the entries in the four data manipulation sections are not included in the .INI file of the first application that starts the database engine, then no application that uses the engine will be able to use FoxPro, dBASE, Paradox, or Btrieve data while the first application is running.

For example, when you start Microsoft Access, it initializes the database engine according to the settings in the MSACC20.INI file.  If you then start Visual Basic version 3.0 while Microsoft Access is still running, the database engine will use the MSACC20.INI file settings rather than the settings in the Visual Basic initialization file.

The following table below shows where each application looks for its initialization information.

Application	INI file
Microsoft Access version 2.0	MSACC20.INI
Microsoft Access version 1.x	MSACCESS.INI
Microsoft Access application	<appname>.INI
Visual Basic at design time	VB.INI
Visual Basic at run time	VB.INI
Visual Basic .EXE application	<appname>.INI
Using Microsoft Access to Import, Attach, or Export to Microsoft FoxPro Version 2.5 Files

Microsoft FoxPro version 2.5 doesn't distinguish between tables created with the MS-DOS version and those created with the Microsoft Windows version.  Data in tables created with FoxPro version 2.5 for MS-DOS is stored in OEM format.  Data in tables created with FoxPro version 2.5 for Windows is stored in ANSI format.  Microsoft Access converts all FoxPro version 2.5 data from an OEM code page to the ANSI 1252 code page when importing or attaching FoxPro 2.5 data, and it converts the ANSI code page to an OEM code page when exporting to FoxPro 2.5 tables.  The result is that extended characters in tables created with FoxPro version 2.5 for Windows aren't converted properly.

If your FoxPro version 2.5 tables contain extended characters, you should be certain that the tables are stored in OEM format (that is, created by FoxPro version 2.5 for MS-DOS).  Releases of FoxPro subsequent to 2.5 (2.5a, 2.5b, and so on) correctly identify the code page format of the data, enabling Microsoft Access to correctly determine how to convert extended characters.

Lotus cc:Mail or Lotus Notes

Microsoft Access supports Vendor Independent Messaging (VIM) 1.0, which means that you can use the Send command on the File menu in Microsoft Access to include Microsoft Access documents in messages to mail applications that support VIM 1.0.  VIM is automatically installed by Lotus cc:Mail version 2.0 (or later) and Lotus Notes version 3.0 (or later).  Lotus cc:Mail version 1.11 users can get VIM support files from Lotus.  The DOS PATH command in the AUTOEXEC.BAT file must include the directory in which the mail application's VIM support files are stored.  Otherwise, the Microsoft Access Setup program will not install support for VIM.  If Microsoft Access VIM support has already been installed, it will not function correctly if the VIM directory is not included in the DOS PATH command.  The Microsoft Access support file for VIM 1.0 is called MAPIVIM.DLL and is stored in the System subdirectory of the Windows program directory.

If you have a system with a large number of users in the address book, you can improve performance by adding a switch in the WIN.INI file to disable the listing of names in the address dialog.  To do this, add the entry MAPIVIMDisableABScan=1 to the [Mail] section of the WIN.INI file.  This will greatly improve the speed of the address dialog.

To uninstall support for VIM 1.0, delete the following line in the [Mail] section of the WIN.INI file:

MAPIDLL=<path>\MAPIVIM.DLL

where <path> is the path to your Windows system directory.

Using Microsoft Access with Microsoft Video for Windows

The following problem can occur if you install Microsoft Video for Windows version 1.1 after you install Microsoft Access version 2.0.  If you install Microsoft Access version 2.0 and the Setup program detects an existing copy of Microsoft Video for Windows version 1.1 on your hard disk, the Setup program will automatically install the new .DLL file that fixes the problem.

There is a problem with Microsoft Video for Windows version 1.1 that may cause a General Protection Fault (GPF) in Microsoft Access 2.0 while browsing video clips in forms.  You may also encounter memory problems with this version of Microsoft Video for Windows.  If your version of the file MCIOLE.DLL (located in your Windows directory) is dated prior to 2/28/94, you should contact Microsoft Product Support Services for Microsoft Video for Windows to obtain a newer version.

Windows NT

If you're running Microsoft Access 2.0 on Windows NT version 3.10 (or Windows NT Advanced Server), you must use the latest version of the Windows NT Service Pack (Service Pack 2 or later).  To verify the exact version of Windows NT you're using, run WINVER.EXE from the Windows NT command prompt.  The second and third lines of the WINVER dialog box should look something like:

Version 3.10
Build 528: Service Pack 2

Windows NT Service Pack is available on CompuServe and through anonymous FTP on the Internet, as well as from Microsoft.  For additional information on obtaining Windows NT Service Pack, consult Your Guide to Service and Support for Microsoft Windows NT, included with Windows NT.

If you're running Windows NT, Microsoft Access Setup will not install the ODBC Administrator application, and there won't be an ODBC icon in the Control Panel.  If you want to add and configure ODBC data sources, you must manually copy the ODBCADM.EX_ file included on Disk 1 in the Microsoft Access package to your hard disk, decompress the file to ODBCADM.EXE, and run the application manually yourself, or create an icon to run it.  For information on creating an icon in Windows NT, see the Microsoft Windows NT System Guide.

Note that if you're running Windows NT, you must have a mouse in order to set up Microsoft Access version 2.0.

Setting Up Microsoft Access on a Novell Network

If you try to install Microsoft Access version 2.0 on a Novell network (using the setup /a command), you may receive the following error message:

Cannot change the properties of the file named SETUP.INI.

If you receive this error message, find the line "READ ONLY COMPATIBILITY=ON" in the SHELL.CFG or NET.CFG file for the workstation from which you are running Setup.  (This line will be located in the "NetWare DOS Requester" section of NET.CFG if you are using Novell NetWare version 4.0).  Change this line to "READ ONLY COMPATIBILITY=OFF", reboot, and run Setup again.

You should no longer receive this error message.

After Microsoft Access is installed, change the option in the SHELL.CFG or NET.CFG file back to =ON in case there are applications on the system that require this setting.

Using Microsoft Access on Novell NetWare Servers and Banyan VINES Servers (Increasing the Number of Record Locks)

On Novell NetWare Servers

If you are attempting to use large Microsoft Access databases on a Novell NetWare server, set the "maximum record locks per connection" to the largest allowable value (10,000).  The execution of large bulk operations in Microsoft Access (such as a large update query) can cause the server to run out of record lock connections.  If you don't set the number of record locks to the maximum value while using Microsoft Access, it could result in the loss of data due to a server crash.

See your Novell NetWare documentation for a description of how to set the number of record locks.

On Banyan VINES Servers

If you are attempting to use large Microsoft Access databases on a Banyan VINES server, you may exceed the number of record locks allowed.  (Note that the number of record locks is not user-definable for Banyan VINES servers.)

Banyan VINES version 4.11 allows a maximum of 500 record locks.  It is conceivable that a large Microsoft Access bulk operation would require that many record locks.  Banyan VINES version 5.00 allows only 100 record locks, which would severely limit Microsoft Access use.  Banyan VINES version 5.5 allows at least 10,000 record locks.  It is recommended that you upgrade to the latest version of Banyan VINES (at least version 5.5 or later) if you want to use Microsoft Access on a Banyan VINES network.

Using Microsoft Access with Microsoft LAN Manager

Using Microsoft Access on an MS-DOS or PC-DOS workstation running a product based on versions of Microsoft LAN Manager prior to version 2.2 (and using the Enhanced redirector) can irreparably corrupt a database file.  Database corruption is most likely to occur when a user workstation operates faster than the file server storing the database file.  (Note that the CPU speed alone does not determine the operation speed of the server.  Heavy network traffic can make the server operate more slowly than a user workstation.)

Products that may be affected include:

DEC Pathworks for DOS version 4.x

Microsoft LAN Manager prior to version 2.2

NCR StarGroup LAN Manager version 3.6

Olivetti Olinet LAN Manager version 2.1

Ungermann-Bass LAN Manager version 2.1

See your network administrator to find out if the information in this section applies to your network software.

To prevent data corruption when using the enhanced version of Microsoft LAN Manager version 2.1 or 2.1a, your network administrator should install the Hotfix that is included on Disk 8 (if your Microsoft Access package includes 3.5-inch disks) or Disk 10 (if your Microsoft Access package includes 5.25-inch disks) in your Microsoft Access package.

To determine your version of Microsoft LAN Manager

Type net ver at the command prompt to determine which version of LAN Manager is installed on the user workstation.

You will see information such as the following:

C:\>NET VER
Microsoft LAN Manager Version 2.1.0
DOS Enhanced Workstation
Created at 11-15-91 07:27am

Proceed to the procedure, "To install the Hotfix on each user workstation," only if the command reports you are using Microsoft LAN Manager version 2.1 or 2.1a.

If the command does not report which version of Microsoft LAN Manager you are using, you are using a version earlier than 2.1.  You need to upgrade the workstation to Microsoft LAN Manager version 2.2 or follow the procedure, "To adapt a workstation using a version of Microsoft LAN Manager earlier than 2.1," at the end of this section.

Important  If you are using network software based on Microsoft LAN Manager and aren't sure which version of Microsoft LAN Manager it corresponds to, do not install the Hotfix.  Instead, follow the procedure, "To adapt a workstation using a version of Microsoft LAN Manager earlier than 2.1."  You can install the Hotfix later if it's determined you need it.

To install the Hotfix on each user workstation

1	Type ver at the command prompt to determine which version of MS-DOS is installed on the user workstation.

2	If you are using MS-DOS version 5.0, 6.0, or 6.2, insert Disk 8 (if your Microsoft Access package includes 3.5-inch disks) or Disk 10 (if your Microsoft Access package includes 5.25-inch disks) from your Microsoft Access package in drive A.  This disk contains the NETWKSTA.50_ file.

3	Using the DECOMP.EXE program located on Disk 1 of your Microsoft Access package, decompress the NETWKSTA.50_ file to the LAN Manager NETPROG directory.  For example, if LAN Manager is currently installed in the LANMAN.DOS directory on drive C, decompress the NETWKSTA.50_ file to C:\LANMAN.DOS\NETPROG\NETWKSTA.EXE.

If you are using MS-DOS version 3.3 or 4.0, you must contact Microsoft Product Support Services to request the appropriate NETWKSTA file.  In the United States, call Microsoft LAN Manager Product Support Services at (206) 635-7020.

4	Reboot the user workstation.

To adapt a workstation using a version of Microsoft LAN Manager earlier than 2.1

To prevent database corruption when using enhanced versions of Microsoft LAN Manager earlier than version 2.1, turn write-behind off by adding or modifying the following line in the [workstation] section of your LANMAN.INI file:

[workstation]
wrkheuristics=X0XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The Xs are placeholders for values in the range of 0-2.  In all, there should be 33 values in this entry, and the second value must be 0 (zero).  See your Microsoft LAN Manager Administrator's Reference for details.

Important   If this line already exists in your LANMAN.INI file, change only the second value to 0 (zero).

Note that adding this line may slightly decrease the performance of your system.

You can also resolve this problem by upgrading to LAN Manager version 2.2 or later.  For details, please contact your network vendor or call Microsoft Customer Service at 1-800-426-9400.

Using Microsoft Access with Microsoft Windows for Workgroups

Important   The following problem can occur if you install Microsoft Access version 2.0, and then install version 3.1 of Microsoft Windows for Workgroups.  If you install Microsoft Access version 2.0 after installing Windows for Workgroups, Microsoft Access Setup will install the driver that fixes this problem automatically if Setup detects an earlier version of the driver on your hard disk, or detects that you're running Windows for Workgroups version 3.1.  (This problem doesn't occur if you're running Windows for Workgroups version 3.11 or later.)

While running Microsoft Windows for Workgroups 3.1, if you use the Network button in Microsoft Access dialog boxes to connect to a password-protected server, you may lose data.  To avoid damaging your database, you must install the updated Microsoft Windows for Workgroups driver included with Microsoft Access.  Until you have installed this driver, do not use the Network button in Microsoft Access dialog boxes to make network connections.

Note   If you are considering installing Windows for Workgroups 3.1 at a later date, install the updated driver now.

To install the updated Windows for Workgroups driver

1	Exit Microsoft Windows or Windows for Workgroups.

This driver cannot be installed while you are running Microsoft Windows.

2	Insert Disk 8 (if your Microsoft Access package includes 3.5-inch disks) or Disk 9 (if your Microsoft Access package includes 5.25-inch disks) from your Microsoft Access package in drive A.  This disk contains the WFWNET.DR_ file.

3	Using the DECOMP.EXE program located on Disk 1 of your Microsoft Access package, decompress the WFWNET.DR_ file to your Windows system directory.  For example, if your Windows system directory is C:\WINDOWS\SYSTEM, decompress the WFWNET.DR_ file to C:\WINDOWS\SYSTEM\WFWNET.DRV.

4	Type win to restart Windows.

If you have any questions about this driver, please contact Microsoft Product Support Services for Windows for Workgroups.

Using SQL Server Data Installed on a Novell NetWare LAN or a Banyan VINES Network

If you use Microsoft Access on a workstation running under Microsoft Windows for Workgroups and want to access SQL Server data installed on a Novell NetWare LAN or a Banyan network, you must use the SQL Server Network Integration Kit (NIK).  For details, see your Network Integration Kit and SQL Server documentation.  If you still have questions, contact Microsoft Product Support Services at one of the numbers listed in the Microsoft Access User's Guide or in Microsoft Access Help.  (Click the Contents button in the Help window and then click Technical Support, or choose the Technical Support command from the Help menu in Microsoft Access.)

Asynchronous Query Execution and ODBC Drivers

When executing queries against Open Database Connectivity (ODBC) data sources, Microsoft Access will attempt, if supported by the ODBC driver, to execute the query asynchronously.  The client-server network libraries supported by some ODBC drivers may experience difficulties while executing queries asynchronously.  If you encounter problems with query execution, you can disable asynchronous execution by adding the following entry to the [ODBC] section of your MSACC20.INI file:

DisableAsynch=1

ORACLE Server Databases and Null Indexes

Some databases, such as ORACLE Server databases, allow multiple Null primary keys in an index, although the index is still considered unique.  Microsoft Access can't modify records that have multiple occurrences of the same unique (Null) value, although it can modify other records in the table.

If you want to modify records in such a database, make sure that each record has a unique primary key and that no more than one of these is Null.


Using Microsoft Access with Btrieve

This topic provides supplementary information on configuring Btrieve for use with Microsoft Access.  Before you import, export, or attach Btrieve tables with Microsoft Access, please read this information.  For basic information on using Btrieve tables with Microsoft Access, see Importing and Attaching Btrieve Tables.

Contents

General Considerations

How Microsoft Access Locates Btrieve Files

Using Databases with Xtrieve-style Security

Using Compressed Data Files

Using Btrieve in a Multiuser Environment

Using Btrieve Indexes

Setting Btrieve Options

Setting Microsoft Access Options for Btrieve

Configuring the Server-based Version (BTRIEVE.NLM)

General Considerations

When using Btrieve data with Microsoft Access, keep the following considerations in mind:

You can use Btrieve data files in either 5.1x format or 6.x format.

You must have the data definition files FILE.DDF and FIELD.DDF, which tell Microsoft Access the structure of your tables.  These files are created by Xtrieve or another .DDF file-building program.

You must have the Btrieve for Windows dynamic-link library, WBTRCALL.DLL, which isn't provided with Microsoft Access.  This file is available with Novell Btrieve for Windows, Novell NetWare SQL, and some other products for Microsoft Windows that use Btrieve.

How Microsoft Access Locates Btrieve Files

Microsoft Access usually looks for Btrieve data files in the same directory as the .DDF file you specify (or in the path stored in FILE.DDF for each data file).  If you want Microsoft Access to locate files in other locations, you can set the XTRPATH variable to list directory paths you want to include.  For example if you want Microsoft Access to look at several directories, you'd set this variable as follows:

XTRPATH=path[;path[;path...]]

You can set the XTRPATH variable in any one of the following places:

In your AUTOEXEC.BAT file, using the SET command as follows:

SET XTRPATH=C:\BTRIEVE\DATA;F:\DATA

In the [Btrieve ISAM] section of your MSACC20.INI file.

In your Btrieve environment (.ENV) file.  For Microsoft Access to recognize this file, you must specify its path and file name by setting the XTRENV variable, either in the AUTOEXEC.BAT file using the SET command, or in the MSACC20.INI file.

For information on setting options in MSACC20.INI, see Setting Microsoft Access Options for Btrieve.

Using Databases with Xtrieve-style Security

If your data-definition (.DDF) files have an owner name, such as when you enable security with Xtrieve, Microsoft Access can't usually use your Btrieve files.  To use files with this type of security, you must specify the owner name using the DDFPassword option in the MSACC20.INI file located in your Windows directory.

For information on setting options in MSACC20.INI, see Setting Microsoft Access Options for Btrieve.

Using Compressed Data Files

If you're using compressed Btrieve files, you must be sure that the compression buffer Btrieve is using is adequate for your data.  The buffer size must be at least as large as the largest record in your data files.

To ensure proper operation, set the compression buffer size option (/u) in the [btrieve] section of your WIN.INI file (for Btrieve version 5.1x) or NOVDB.INI file (for Btrieve version 6.x).  The units for this setting are kilobytes, so if your largest record is 2K, you would add /u:2 to the Btrieve options line in WIN.INI.

For more information on setting options, see Setting Btrieve Options.

Using Btrieve in a Multiuser Environment

If you're using Btrieve in a multiuser environment, you must use the same transaction file (BTRIEVE.TRN) as other users on the network.  To do this, set the transaction file name option (/t) in the [btrieve] section of your WIN.INI file (for Btrieve version 5.1x) or NOVDB.INI file (for Btrieve version 6.x).  Use this option to point to the network location of BTRIEVE.TRN.

For more information on setting options, see Setting Btrieve Options.

Using Btrieve Indexes

Microsoft Access automatically uses indexes in attached Btrieve tables when searching or sorting.  However, the following types of indexes aren't supported:

Indexes defined with the Btrieve index attributes Manual or Null

Indexes that have an alternate collating sequence specified

Compound (segmented-key) indexes where one or more segments of the key are only partial fields

To get the best performance when you use attached Btrieve tables, make sure your indexes aren't one of these types.

For information about Btrieve indexes, refer to the Btrieve Programmer's Manual.

Setting Btrieve Options

Option settings that are shared by all Btrieve for Windows applications are stored in your WIN.INI file (for Btrieve version 5.1x) or NOVDB.INI file (for Btrieve version 6.x).  It's important that these option settings are compatible with all your applications that use Btrieve for Windows.  Most of these applications add a [btrieve] section such as the following to either WIN.INI or NOVDB.INI; the following sample settings are most appropriate for Microsoft Access:

[btrieve]
options=/m:64 /p:4096 /b:16 /f:20 /l:40 /n:12 /t:C:\ACCESS\BTRIEVE.TRN

If this section doesn't exist in WIN.INI when you install Microsoft Access, Setup adds the preceding settings automatically.  However, if the line already exists in WIN.INI, Microsoft Access adds a second options line beginning with "access_options."  This line is for information purposes only; it contains the default settings for use with Microsoft Access.  If your existing settings on the "options" line are different, you may need to replace them with those on the "access_options" line.

If you're using Btrieve version 6.x files, the option settings specified in NOVDB.INI apply instead of those in WIN.INI.  However, Microsoft Access doesn't set options in NOVDB.INI.  If you don't have an options line in NOVDB.INI such as the preceding example, you must set these options appropriately in NOVDB.INI before using Microsoft Access with Btrieve 6.x files.

Although the preceding Btrieve option settings shown are those recommended for use with Microsoft Access, you can change them using the following table as a guide.  Using a text editor, open your WIN.INI file or NOVDB.INI file (both located in your Windows directory).  If the option you want to set is not on the options line, add the option and desired setting at the end.

Option	Description	Required value
/m	Memory size	At least 38
/p	Page size	4096
/b	Pre-image buffer size	16
/f	Open files	At least 4
/l	Multiple locks	At least double the setting for the Open Files option (/f)
/n	Files in a transaction	At least 4
/t	Transaction file name	Valid path to a .TRN file; in a multiuser environment, network path to the .TRN file shared by all users
/u	Compression buffer size	If your Btrieve data files are compressed, at least the length (in kilobytes) of the longest record in your data files
Setting Microsoft Access Options for Btrieve

The Microsoft Access initialization file MSACC20.INI, located in your Windows directory, contains a [Btrieve ISAM] section that stores settings for how Microsoft Access works with Btrieve files.  Although Microsoft Access automatically uses recommended option settings, you can add lines with your own settings to the [Btrieve ISAM] section using the following table as a guide.

Option	Description	Example
DataCodePage	Determines the code page used for reading and writing text data.  Possible values are OEM and ANSI.   The default is OEM.	DataCodePage=ANSI
OpenAccelerated	Determines whether Microsoft Access uses Btrieve accelerated access.  If you set this to On, all other applications sharing the same tables must also use accelerated access. The default is Off.	OpenAccelerated=On
NetworkAccess	Determines whether Microsoft Access uses file locking.  If set to Off, Btrieve tables are opened exclusively regardless of how you specify options when opening the table. The default is On.	NetworkAccess=Off
PageTimeout	The length of time between when data is placed in an internal cache and when it's marked to be refreshed.  The settings are expressed in 100 millisecond units. The default is 600 (60 seconds).	PageTimeout=50
DDFPassword	The owner name used when opening FILE.DDF.  You must set this option when Xtrieve-style security is enabled for your DDF file.	DDFPassword=myname
IndexDDF	Determines whether Microsoft Access creates and maintains the INDEX.DDF file.  Use the Maintain setting if you want Microsoft Access to update INDEX.DDF when it exists.  Use the Require setting to always create or maintain an INDEX.DDF file. The default setting is Ignore, with which an INDEX.DDF file is never created or maintained.	IndexDDF=Maintain
XTRPATH	The list of file paths that Microsoft Access searches when trying to open Btrieve data files.	XTRPATH=c:\data;m:\data
XTRENV	The location and file name of an Xtrieve-style environment (.ENV) file that includes an XTRPATH setting.	XTRENV=c:\windows\myown.env
XTRPINDX	A number indicating which of the directories that you specified in the XTRPATH variable that Microsoft Access should use for newly created Btrieve data files. For example, a value of 2 indicates the second directory listed in the XTRPATH variable.	XTRPINDX=2
Configuring the Server-based Version (BTRIEVE.NLM)

If you're using the server-based version of Btrieve (BTRIEVE.NLM), there are several considerations you must keep in mind about your configuration.  Before you use Btrieve data with Microsoft Access, you should check for the following:

You must have the following section in your WIN.INI file (for Btrieve version 5.1x) or NOVDB.INI file (for Btrieve version 6.x):

[BREQUESTDPMI]
datalength=4096
tasks=10
local=no
chkparms=no

You must have transactions enabled on your NLM server (specify the -T option in the BSTART.NCF file on the server).

You must be using version 6.x of the NLM requestor files BREQUEST.EXE, WBTRCALL.DLL, and WBTRVRES.DLL, even if you're using version 5.x of BTRIEVE.NLM.

If you don't have the correct versions of these files, you won't be able to use Btrieve with Microsoft Access.  If you have access to CompuServe, you can download the necessary files for this configuration using the following instructions.  If you don't have a CompuServe account, contact your Novell representative and ask for the 6.0 versions of the requestor files.

To update your Btrieve NLM files from CompuServe

1	Connect to CompuServe and type go novlib

2	Go into the Btrieve/XQL library section.

3	Download the self-extracting file BT515.EXE, and then run the file to unpack it.

4	Unpack the file BTRREQ.EXE (one of the files from BT515.EXE).

5	Follow the instructions in the Readme file for installing the resulting files and applying necessary patches to the BTRIEVE.NLM file on your server.


Files Included with Microsoft Access

Contents

Outdated Version 1.0 and Version 1.1 Files

Microsoft Access Version 2.0 Files

This section lists the outdated files from Microsoft Access versions 1.0 and 1.1, and the files supplied with Microsoft Access version 2.0.

Outdated Version 1.0 and Version 1.1 Files

If you are installing Microsoft Access version 2.0 in the same directory as an existing copy of version 1.0 or version 1.1, the Microsoft Access Setup program installs the version 2.0 files and at the same time deletes or replaces outdated version 1.0 and version 1.1 files.

The following files are no longer used by Microsoft Access, and are deleted by Setup:

BTRIEVE.TXT	BTRVISAM.DLL	CBTLIB4.DLL
CUECARD.EXE	CUECARDS.DLL	CUECARDS.LES
DBSISAM.DLL	DETCMD.DLL	ERRATA.TXT
MSA110.HLP	MSABC100.DLL	MSACCESS.EXE
MSACCESS.HLP	MSAES100.DLL	MSAFIN.DLL
MSAIN100.DLL	MSAIN110.DLL	MSAJT100.DLL
MSAJU100.DLL	MSAJU110.DLL	PDXISAM.DLL
PERFORM.TXT	PSSKB.TXT	README.TXT
README_.TXT	SETUP.INI	STFSETUP.EXE
STFSETUP.INF
For a complete list of the version 2.0 files, see Microsoft Access Version 2.0 Files.

Microsoft Access Version 2.0 Files

Note   The directory names shown are the most common name for this directory; however, the directory name on your machine may be different.  For example, your Windows directory may be called WIN31 or just WIN.  The name <install directory> indicates the directory where your Microsoft Access program files were installed.

Files to go in <install directory>

Minimum Install:

ACREADME.HLP	Readme for Microsoft Access version 2.0

CONSTANT.TXT	Constants for Access Basic

MSACCESS.EXE	Microsoft Access executable

MSAFIN.DLL	Microsoft Access DLL

MSAIN200.DLL	Microsoft Access DLL

MSAJU200.DLL	Microsoft Access DLL

MSAOLE20.DLL	Microsoft Access DLL

MSAU200.DLL	Microsoft Access DLL

README.TXT	Text file pointing to ACREADME.HLP

SOA200.DLL	Save output as

UTILITY.MDA	Utility Library database

WRKGADM.EXE	Workgroup administrator

WZLIB.MDA	Wizard Library

Typical/Custom Install:

MSACC20.HLP	Microsoft Access Help file

MSACCARD.DLL	Cue Cards Library

MSACCESS.CUE	Cue Cards data

MSACCPSS.HLP	Microsoft Access Product Support Services Help file

WZBLDR.MDA	Builders Library

WZFRMRPT.MDA	Wizards Library

WZQUERY.MDA	Query Wizards

WZTABLE.MDA	Table Wizard

WZTBLDAT.MDT	Data for the Table Wizard

Files to go in <install directory>\SETUP

Minimum Install:

SETUP.STF	Setup file

Typical/Custom Install:

_MSSETUP.EXE	Setup program

ACMSETUP.HLP	Setup Help file

ACSETUP.TTF	Setup file

DECOMP.EXE	Decompression program

MSACAHBB.DLL	Setup DLL

MSCPYDIS.DLL	Setup DLL

MSSETUP.DLL	Setup DLL

ODBCINST.DLL*	ODBC file

SETUP.EXE	Setup program

SETUP.INF	Setup file

SETUP.INI	Setup file

* Duplicate file (also appears in WINDOWS\SYSTEM when installing ODBC).

Files to go in <install directory>\SAMPAPPS

Typical/Custom Install:

NEWCUST.DBF	Sample dBASE file

NWIND.MDB	Northwind Traders sample database

ORDERS.HLP	Orders Help file

ORDERS.MDB	Orders database

SOLUTION.HLP	Solutions Help file

SOLUTION.MDB	Solutions database

Files to go in \WINDOWS

Minimum Install:

MSACC20.INI	Microsoft Access INI file

Typical/Complete Install:

CCARD200.EXE	Cue Cards file

Files to go in \WINDOWS\SYSTEM

Minimum Install:

COMPOBJ.DLL	OLE DLL

CTL3DV2.DLL	Control 3D V2 DLL

DAO2016.DLL	DAO DLL

MSABC200.DLL	Access Basic DLL

MSAEXP20.DLL	Microsoft Access Expression Service DLL

MSAJT200.DLL	Jet DLL

MSJETERR.DLL	Jet DLL

MSJETINT.DLL	Jet DLL

MSTOOLBR.DLL	Microsoft Access DLL

OLE2.DLL	OLE DLL

OLE2.REG	OLE Registration file

OLE2CONV.DLL	OLE DLL

OLE2DISP.DLL	OLE DLL

OLE2NLS.DLL	OLE DLL

OLE2PROX.DLL	OLE DLL

STDOLE.TLB	OLE Typelib

STORAGE.DLL	OLE DLL

TYPELIB.DLL	OLE DLL

Typical Install:

CCAPI200.DLL	Cue Cards file

PDX200.DLL	Paradox ISAM

SCP.DLL	Graph 5.0 DLL

SDM.DLL	Graph 5.0 DLL

XBS200.DLL	Xbase ISAM

Custom Install:

BTRV200.DLL	Btrieve ISAM

CTL3D.DLL	Control 3D DLL

DBNMP3.DLL	SQL Server

DRVACC2.HLP*	Access 2.0 ODBC Driver

DRVSSRVR.HLP	SQL Server Help

ODBC.DLL	ODBC DLL

ODBCINST.DLL	ODBC DLL

ODBCINST.HLP	ODBC Help

ODBCJT16.DLL*	Access 2.0 ODBC Driver

ODBCTL16.DLL*	Access 2.0 ODBC Driver

SQLSRVR.DLL	SQL Server

* These files will be installed in your Typical install if the Microsoft Access version 1.1 ODBC driver is present on your system.

MAPIVIM Install:

MAPIVIM.DLL*	MAPI to VIM DLL

* This file will be installed if you choose the MAPIVIM interface in setup.

Files to go in \WINDOWS\MSAPPS\MSGRAPH5

Typical/Custom Install:

AUTOCONV.EXE	Microsoft Graph 5.0 Autoconvert Utility

GRAPH5.EXE	Microsoft Graph 5.0

GREN50.OLB	Microsoft Graph 5.0 Object Library

GRINTL.DLL	Microsoft Graph 5.0 DLL

MSGRAPH.HLP	Microsoft Graph 5.0 Help

Files to go in \WINDOWS\MSAPPS\MSINFO

Minimum Install:

MSINFO.EXE	Microsoft System Info Utility

Files That May Be Updated on Your System

If Microsoft Access Setup finds outdated versions of the following files, they will be updated.

File in \WINDOWS

MCIOLE.DLL	OLE driver for Video for Windows 1.1

Files in \WINDOWS\SYSTEM

VER.DLL	Version DLL

VSHARE.386	Windows for Workgroups file-locking driver

WFWNET.DRV	Windows for Workgroup network driver


IsolateODBCTrans Property (Data Access)
IsolateODBCTrans Property

See Also	Example	2.0

Applies To

Workspace objects.

Description

Isolates multiple transactions that involve the same Open Database Connectivity (ODBC) database.

Setting

The IsolateODBCTrans property settings are:

Setting	Description

True	Isolate transactions involving the same ODBC database.

False	(Default) Do not isolate transactions involving the same ODBC database.

Usage

This property setting is read/write.

Remarks

In some situations, you will need to have multiple simultaneous transactions pending against the same ODBC database.  To do this, you need to open a separate Workspace object for each transaction.  Although each Workspace object could have its own ODBC connection to the database, this degrades system performance.  Since transaction isolation isn't usually required, ODBC connections from multiple Workspace objects opened by the same user are shared by default.

Some ODBC servers (such as Microsoft SQL Server) don't allow simultaneous transactions on a single connection.  If you need to have more than one transaction at a time pending against such a database, set the IsolateODBCTrans property to True on each Workspace object as soon as you open it.  This will force a separate ODBC connection for each Workspace object.


IsolateODBCTrans Property See Also
See Also

Help:

BeginTrans, CommitTrans, Rollback Methods

Workspace Object, Workspaces Collection

Building Applications:

Chapter 11, "Working with Sets of Records"


IsolateODBCTrans Property Example

This example opens a Workspace object and sets IsolateODBCTrans to True before starting a transaction.

 Dim MyWs As Workspace, MyDb As Database, MyRs As Recordset

    Set MyWs = DBEngine.Workspaces(0)
    Set MyDb = MyWs.Databases(0)
    Set MyRs = MyDb.OpenRecordset("Query to ODBC Database")

    MyWs.IsolateODBCTrans = True
    MyWs.BeginTrans
    MyRs.AddNew
    ...	' Add new data.
    MyRs.Update


DistinctCount Property (Data Access)
DistinctCount Property

See Also	Example	2.0

Applies To

Index objects.

Description

Indicates the number of unique values for the Index object that appear in the associated table.

Setting

The DistinctCount property is a Long value.

Usage

This property setting is read-only.

Remarks

Check the DistinctCount property to determine the number of unique values (or "keys") in an index.  Any one key is counted only once, even though there may be multiple occurrences of that value if the index permits duplicate values.  This information is useful in creating Wizards or other applications that attempt to optimize data access by evaluating index information.

The DistinctCount property won't always reflect the actual number of keys at a particular time.  For example, a change caused by a rolled-back transaction won't be immediately reflected in the DistinctCount property.


DistinctCount Property See Also
See Also

Help:

Index Object, Indexes Collection

User's Guide:

Chapter 8, "Changing and Customizing Tables"


DistinctCount Property Example

This example checks the DistinctCount property of the current Index of a TableDef object opened on a table in the NorthWind database.

Dim MyWs As Workspace, MyDb As Database
    Dim MyTD As TableDef, MyInd As Index
    Dim C As Long

    Set MyWs = DBEngine.Workspaces(0)
    Set MyDb = MyWs.OpenDatabase("NWIND.MDB", True)
    Set MyTD = MyDb.TableDefs("Customers")
    Set MyInd = MyTD.Indexes(0)
    C = MyInd.DistinctCount


version 2.0

This element was introduced in Microsoft Access version 2.0.