Microsoft Access Readme Help Contents

Main Help Contents

Microsoft Access Product Update

Late-breaking information about this release of Microsoft Access.

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.

Conversion and Compatibility Updates

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

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

Using SHARE.EXE

To run Microsoft Access version 2.0, you must have the Share program installed on your computer.  Under most circumstances, the Microsoft Access Setup program will automatically install Share and modify your AUTOEXEC.BAT file.  If you try to run Microsoft Access when Share is not installed, you will receive an error message.  To load Share:

If you are running Microsoft Windows for Workgroups, run it in 386 enhanced mode.

-Or-

Add the following line to your AUTOEXEC.BAT file

<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

You may need to add this line if it was removed from your AUTOEXEC.BAT file or if Setup was unable to add it.

If you are running Microsoft Windows in Enhanced Mode with an 80386 or higher microprocessor, you should use the vshare.386 version of share.  Microsoft Access installs this version automatically if you have such a configuration on your computer.

If you don't have Share installed when you install Microsoft Access, and you aren't running in Enhanced Mode, the Setup program will install share.exe.  In doing so, the Setup program makes changes to the AUTOEXEC.BAT file.  These changes can cause problems if you are using a third-party memory manager program.  (Microsoft Access will run correctly, but the memory manager may not.)

If you have a multi-configuration system, the Setup program will only install Share for the first instance it encounters.  Everything after the first instance has to be modified by hand.

Renaming, Deleting, or Moving Files and Directories

You may get unpredictable results if you do any of the following:

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, choose the Add/Remove button, and then follow the instructions in Setup.

Files That Must Be Installed Locally

Regardless of the Setup options you choose, Setup must install certain files in your WINDOWS directory 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.

Unused Error Messages

The following error messages are no longer used by Microsoft Access or have been replaced by other error messages.

Message	Value
errOutOfMemory	3035
errOutOfBuffers	3038
errRmtDataOverflow	3147
errRmtConnectFailed	3148
errRmtIncorrectSqlcDll	3149
errRmtMissingSqlcDll	3150
errRmtDrvrVer	3152
errRmtSrvrVer	3153
errImexOutOfMemory	3178
errRmtOdbcVer	3233
errRmtUnexpectedNull	3236
errRmtUnexpectedType	3237
errODBCParmsChanged	3255
Special Notes on Using Microsoft Access Version 2.0 with Other Software

Visual Basic

Microsoft Access version 2.0 contains a later version of the 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 the Using Visual Basic 3.0 Applications section below.

Windows NT

For best results using Microsoft Access 2.0 on Windows NT version 3.10 (or Windows NT Advanced Server), use the Windows NT Service Pack version 1.0 or later.  To verify the exact version of Windows NT, run WINVER.EXE from the Windows NT command prompt.  The second line of the WINVER dialog box should read "Version 3.10 (build 528: CSD002)" or later.  Windows NT Service pack version 1.0 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 version 1.0 (and later versions of the Service Pack), consult Your Guide to Service and Support for Microsoft Windows NT, included with Windows NT.

If you're running under 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.EXE file included on Disk 1 in the Microsoft Access package to your hard disk, decompress the file, and run it yourself.

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 send Microsoft Access documents with 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 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.

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 the Microsoft Access setup program finds an earlier driver used to access Microsoft Access data, the Microsoft Access 2.0 Driver for Microsoft Access is installed on your hard disk.  You can use this driver to access and manipulate Microsoft Access data from Microsoft Word or Microsoft Excel.  However, this driver is only certified to work with Word and Microsoft Excel; do not use this driver from other ODBC client applications.

Also, don't use this driver to access data in other ODBC applications from Microsoft Access, or to access Microsoft Access data from Microsoft Access.  Microsoft Access has built-in drivers for these tasks.

Using Microsoft Access with Microsoft LAN Manager

The following problem may occur when using products based on Microsoft LAN Manager versions prior to 2.2 on your MS-DOS or PC-DOS workstation.

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 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(s).)

Products that may be affected include:

DEC Pathworks for DOS version 4.1

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 9 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 prior to 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 prior to 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	Insert Disk 9 in drive A.

3	Copy the appropriate NETWKSTA file on Disk 9 to the LAN Manager NETPROG directory and rename the file NETWKSTA.EXE.  You should use the NETWKSTA.500 file for both MS-DOS version 5.0 and MS-DOS version 6.0.  For example, if LAN Manager is currently installed in the LANMAN.DOS directory on drive C, and you are using MS-DOS version 5.0, type:

copy a:netwksta.500 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 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

Note:   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 Microsoft Product Support at the numbers listed in your Microsoft Access User's Guide or in Microsoft Access Help.  (From the Help menu, choose Contents, and then click Product Support.)

Warning When Attaching Tables with Unsupported Collating Sequence

If you attach an external table in another database format, such as Microsoft FoxPro, and the table uses an international collating sequence, it's possible that the Jet database engine doesn't support the collating sequence.  If you modify such a table with Microsoft Access, it's possible to corrupt the table's 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

International Issues

If you're using a Hungarian or Czech database and you attempt to perform LIKE or INSTR (on a non-indexed field) you won't find a match for several characters:

Hungarian:

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

Czech:

CH

The above characters are contractions:  characters that are considered as one character.  Microsoft Access will sort these characters correctly, but any attempt to perform a LIKE or INSTR using these characters (such as "LIKE DZ*") will not result in a match even if a match exists.


Network Installations

Designating Network Connections

In this document, 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.

You must install the 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 applications, they must be logged off from the network.  The directories that contain shared components on the file server or shared volume must be locked from user access [image] for example, W:\WINDOWS and W:\MSAPPS.  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.

Each workstation that will have a complete copy of Microsoft Access must have 15 megabytes (MB) of free hard disk space (or at least 8 MB for a minimum installation).  A workstation that runs Microsoft Access from the network requires 1 MB.  An installation on a network server requires 15 MB.  Setup will alert you if you don't have enough hard disk space.

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 Windows version 3.1, it can run Microsoft Access, provided that it has sufficient RAM and disk space.  The Microsoft Access program requires 15 MB of available space on the file server or the shared directory.  The shared components of Microsoft Access require 5 MB of available space.

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  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.

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, it's a good idea to make the program directory read-only so that users can't delete the files.

You must also create a shared SYSTEM.MDA file for each workgroup in your system.  For details on creating and maintaining workgroups, see Chapter 14, "Securing Your Application," in Microsoft Access Building Applications.  Note that the directory you specify for the SYSTEM.MDA file must not be read-only.

Creating Custom Installations for Workstation Users

You can create scripts to run Setup "silently" (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 silently.

Control which type of installation [image] Typical, Complete/Custom, 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.  For example, 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.

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.

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 file SETUP.STF from the directory in which you installed the main Microsoft Access program and give it 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 table in a spreadsheet application such as Microsoft Excel.

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 third column:

Typical
Complete/Custom
Laptop (Minimum)
Workstation

Type yes in the column labeled "Install During Batch Mode" to the left of the type of installation you want the script to perform.  Type no next to the other options.

3.	If you want the script to perform a Complete/Custom installation, scroll down until you see the following list of components in the third column:

Microsoft Access
Custom Setup Options

Type yes in the column to the left of each component you want the script to install.  Type no next to the other options.

4.	To specify a directory where Setup will install Microsoft Access, scroll through the table until you see "%1" in the column labeled "DestDir."  Replace the "%1" with the name of the directory where you want Setup to install Microsoft Access.

Important   To ensure that Setup works properly, do not edit any other part of the table 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 table 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).

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 tablename	Substitute the name of the new script for tablename.

/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 [image] where X designates the file server [image] and distribute a silent script that uses the MYSCRIPT.STF table 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

Distributing a Script with Microsoft Mail

If you use Microsoft Mail to distribute a script:

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.

To attach the Microsoft Access Setup icon to the command line:

1	Choose the Insert Icon button in Object Packager.

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

3	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

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

Book: Microsoft Access User's Guide

Pages: 12-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 near the bottom this page, just before the Note:

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

Page: 687

Appendix: B, "Working with Toolbars

Add the following note under the section "Customizing Toolbars":

Note   You can't import or export custom toolbars with a database.  The Import and Export commands on the File menu will not transfer custom toolbars.

Book: Microsoft Access Building Applications

Page: 114

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: 189

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: 193

Chapter: 8, "Events"

The first row of the table in the "Error and Timing Events" section says you can cancel error events.  This is not true.  However, setting the Response argument to DATA_ERRCONTINUE in an Error event procedure ignores the error, which is functionally similar to canceling the event.

Page: 287

Chapter 13, "Communicating with Other Applications"

The introductory paragraph to the 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: 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.  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 you can choose from when the wizard is selected, specify the text after the Integer argument or its placeholder.  If you dont specify an Integer argument, you must still type a comma as a placeholder.  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'

Help: MSACC20.HLP

New DAO Properties:  IsolateODBCTrans Property, DistinctCount Property

These properties were added to Microsoft Access too late for their Help topics to be included in the main Help file.  Click the property name below to view a description of the property.

IsolateODBCTrans Property

DistinctCount Property

Keyboard Events (KeyDown, KeyUp, KeyPress)

Keyboard events do not 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.  These key and key combinations are:

SHIFT+F1, F1, SHIFT+F2, CTRL+F2, CTRL+N, CTRL+P, CTRL+O, CTRL+S, CTRL+A, CTRL+F, CTRL+H, CTRL+X, SHIFT+DEL, CTRL+C, CTRL+INS, SHIFT+INS, CTRL+V, DEL, CTRL+Z, ALT+BKSP, CTRL+TAB, SHIFT+CTRL+TAB, and CTRL+F4 (whenever a pop-up form isn't active).

In addition, the following keys and key combinations don't trigger keyboard events when Access Basic code or a macro are running:

F11, F12, CTRL+F11, SHIFT+F12, ALT+F1, ALT+F2, CTRL+ALT+F1, ALT+SHIFT+F2

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.

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.

Enabled, Locked Properties

Embedding a Graph That Displays Data from Microsoft Access

Embedding a Graph That Displays Data from Other Applications

Add the following note to each of these topics:

Note

If your form includes an embedded or linked graph created with Microsoft Graph, note that you cannot lock this object by setting its Locked property to Yes.  Even if you set this property to Yes, you'll be able to make changes to the graph from Form view.  If you do not want to allow users to edit the graph from Form view, be sure to set the graph's Enabled property to No.

OLE applications other than Microsoft Graph can also cause the same problem.

Refresh Method (Data Access)

Add the following note:

Note   Changes to data access objects made through the 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 call 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 via code, it may not be reflected in the Access user interface until the interface is refreshed.  For example, if you delete a table in a module, it may still appear in the Database window until you click on another object type and then click Tables again.

Requery Method

Creating a Subform

Using a Calculated Field in a Query

Add the following note to each of these topics:

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.

RunMacro Action

The sentence:

If you run a macro containing the RunMacro action in a library database, Microsoft Access looks for the macro with this name first in the library database, then in the current database.

should be changed to:

If you run a macro containing the RunMacro action in a library database, Microsoft Access looks for the macro with this name in the library database, and does not look for it in the current database.

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.

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.


Conversion and Compatibility Updates

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.  This will improve performance.

Using Visual Basic 3.0 Applications

If you or others use a Visual Basic 3.0 application to access data in your database file, you must upgrade the Visual Basic application before it can use data in a version 2.0 database.  Wait to convert your 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 using the compatibility layer to upgrade your Visual Basic application, see the compatibility layer Readme file (ACC2COMP.TXT) on the Compatibility Layer disk in the Microsoft Access Developer's Toolkit program disks.

Converting a "Frontend/Backend" 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 "frontend/backend" application), you must 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.

Setup Removes Microsoft Access Version 1.x files

If you install Microsoft Access 2.0 into a directory that contained a previous version of Microsoft Access and if you upgrade from version 1.0 or 1.1, Setup will replace or remove most version 1.1 files.  This applies only to application files, not your data files such as databases.

Owner Access Queries

In Microsoft Access 1.x, queries that ran with Owner permissions were not allowed to reference attached tables.  This restriction has been removed in Microsoft Access 2.0, which now enables users who employ the split back-end/front-end distribution strategy to use Owner-Permission queries to access selected columns or rows of attached tables.

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, like 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) 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) with a !:

People!Name

In general, you should always use an ! (exclamation point) rather than a .(dot) when referring to object names.

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 to convert to Microsoft Access 2.0.

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.

Exporting to Version 1.1 Databases

Although it isn't mentioned in the documentation, you can export tables from your version 2.0 databases to version 1.1 databases using the Export command.  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 2.0 database.  Note, however, that this applies only to tables; you can't export queries, forms, or other objects to 1.1 databases.

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 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.

DefaultValue Property Returns Quote Marks in Version 2.0

In a version 1.x database, the DefaultValue property returns a string value without quotation marks.  In a version 2.0 database, the property returns a string value with 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"


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 in the main Microsoft Access Help file.

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 Windows that use Btrieve.

How Microsoft Access Locates Btrieve Files

Microsoft Access normally 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 filename 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 normally 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 filename 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 preceeding 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 such as the above in NOVDB.INI, you must set these options appropriately in NOVDB.INI before using Microsoft Access with Btrieve 6.x files.

Although the Btrieve option settings shown above 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 filename 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 in which you want Microsoft Access to create new 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 youre 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 instructions below.  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 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

Text to come.


IsolateODBCTrans Property

See Also	Example

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	Do not isolate transactions involving the same ODBC database (default).

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 for each transaction.  Although each Workspace could have its own ODBC connection to the database, this degrades system performance.  Since transaction isolation is not normally required, ODBC connections from multiple Workspace objects opened by the same user are shared by default.

Some ODBC servers (such as Microsoft SQL Server) do not 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 (-1) on each Workspace as soon as you open it.  This will force a separate ODBC connection for each Workspace.


See Also

Help:

BeginTrans, CommitTrans, and Rollback Methods

Workspace Object, Workspaces Collection

Building Applications:

Chapter 11, "Working with Sets of Records"


IsolateODBCTrans Property Example

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

Dim MyDB As Database, MyWS As Workspace, MyQuery As QueryDef

Set MyWS = DBEngine.Workspaces(0)
MyWS.IsolateODBCTrans = True
MyWS.BeginTrans
' Execute query to ODBC database and complete transaction
'...
'...


DistinctCount Property

See Also	Example

Applies To

Index object.

Description

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

Setting

The KeyCount property is a Long data type.

Usage

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 occurences 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 will not always reflect the actual number of keys at a particular time.  For example, a change caused by a transaction rollback will not be immediately reflected in the DistinctCount Property.


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 MyDB As Database, MyTD As TableDef, MyIND As Index
Dim C As Long

Set MyDB = DBEngine(0).OpenDatabase("NWIND.MDB", True)

Set MyTD = MyDB!Customers
Set MyIND = MyTD.Indexes(0)
C = MyIND.DistinctCount