Select the Advanced tab to provide additional parameters for your data source.
Complete the fields as described below.
File Case
From the File Case list box, select the case of the indexed or relative filenames in your destination directory. By default, on Windows systems, the filenames are recognized in either upper or lower case. If your files are on a UNIX system, selecting "Default" enables you to access tables regardless of whether they are named in uppercase or lowercase letters. If you select "Upper," you can see XFDs in either case, but you can access only tables that are named in uppercase letters. In the reverse, if you select "Lower," you can see XFDs in either case, but you can access only tables that are named in lowercase letters.
Compiler Option
Information about representing numeric compressed data is not contained in the COBOL data file. If you specified the "-Dci", "-Dcm", or "-Dcn" compiler option when compiling your ACUCOBOL-GT program, select that option from the Compiler Option list box. This tells AcuODBC which data storage convention was used to create your data files. Other conventions, like "-Dm", are recognized automatically. Possible values include:
| Value | Description |
| Default (-Dca) | The ACUCOBOL-GT storage convention |
| -Dci | The IBM storage convention |
| -Dcm | The Micro Focus storage convention |
| -Dcn | A derivative of the IBM storage convention. Uses the same format as "-Dci" , except that the positive COMP-3 items use "x0B" as the positive sign value instead of "x0C". |
Character Set
Nearly all Windows applications use the ANSI character set, but Vision files may contain OEM characters if they were created using a DOS runtime.
You must tell AcuODBC whether the Vision files in your DSN contain ANSI or OEM characters so it can make the necessary conversions.
If the "Character Set" box contains "OEM", AcuODBC converts alphanumeric fields from OEM to ANSI when reading from Vision files, and from ANSI to OEM when writing to Vision files.
If the "Character Set" box contains "ANSI" (the default), AcuODBC does not convert characters when reading from or writing to Vision files.
The ANSI and OEM representations of the following standard English characters are identical:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789
<space>
! " # $ % & ' ( ) * + , - . / :
; < = > ? @ [ \ ] ^ _ ` { | } ~
Only the representations of accented vowels and other special or non-English characters are different. Therefore, some Vision files created using a DOS runtime need no conversion.
Open Tables
Some applications that use ODBC close and reopen the same tables repeatedly. This is inefficient, since closing and reopening a table can consume system resources.
AcuODBC keeps a queue of tables that the application has most recently ordered closed. AcuODBC keeps these tables open, but marks them so that any attempted operations on them will be rejected until they are reopened. Because some operating systems limit the number of open files, the ODBC administrator can control the maximum number of tables in the queue.
The Open Tables spin box enables you to indicate the maximum number of tables that are kept in the queue in the interest of greater efficiency. You may indicate a queue of anywhere between 1 and 1000, inclusive, tables. If you set Open Tables to zero, which is the default, the feature is disabled and no tables are kept in the queue.
Character Types
The value of this field indicates whether AcuODBC should retain or remove trailing spaces in character data. Use the dropdown list to indicate one of the following three values:
| Mixed | Treat character data as in previous versions (to maintain compatibility). Report the column as SQL_CHAR, but remove trailing spaces (as if it were SQL_VARCHAR). |
| CHAR | Report the column as SQL_CHAR type and do not remove trailing spaces. |
| VARCHAR | Report the column as SQL_VARCHAR and remove trailing spaces.
|
The choices on the drop down list indicate how AcuODBC should treat non-numeric data in a numeric field.
| To | Select |
| Treat non-numeric data in a numeric field as an assignment error | Error. This is the default. |
| Treat the first non-numeric character in a numeric field as the end of the numeric data (thus truncating the numeric data) | Truncate |
| Cause the field to be returned to the application as "0" if the field contains any non-numeric data | Zero |
Some applications must read data based on the key. If a numeric column of a key field contains non-numeric data, the application will be unable to find the correct row of the file and may show an error. Note that, in particular, Microsoft Access 97 selects the columns of the primary key and then selects the rest of the data based on those key columns. If Access cannot read the data (because a user operation has changed the data, and therefore the wrong data is in the key), the affected records show as DELETED. In this case, you must fix the data in the primary key.
Signed Index
AcuODBC does not normally use indexes (also called keys) containing signed numeric data items, because there can be a problem with record ordering when numeric data items contain negative values. This guarantees correct results, but degrades performance because such indexes cannot be used to find or order records.
If your data source indexes contain signed numeric data items, but there are no negative values in them, you can improve performance by selecting the Signed Index check box. This causes AcuODBC to use such indexes.
Read Only
This option is available only for read/write versions of AcuODBC. This entry establishes the default read/write permission for all the files belonging to this DSN. Select the check box (the default) if the files are read-only. Clear the check box if the users can write to the data file (that is, if the files are read/write). Field (column) level read/write protection can be further defined by adding the ACUODBC READ-ONLY and ACUODBC HIDDEN directives to the file descriptor (FD) for your COBOL program.
What you indicate for read/write permission here applies to all files in the data source. If you want to assign different permissions to any individual files, you can do so using the File Alias tab. See section 3.7, "File Aliases" for more information.
GUI Dialog
Select the check box (the default) if you want to see system messages, such as the status of your temporary license, if your site has one, as it nears expiration. Clear the check box to suppress these messages.
Table Name Cache File
Select or clear this check box to indicate whether you want to cache the names of tables. Without a table name cache file, the AcuODBC driver must read and scan the directory for ".xfd" files every time a table is opened. This can affect performance significantly if the number of tables is large and tables are opened and closed frequently.
If the Table Name Cache check box is selected when you connect to a data source, one of two things occurs:
Storing this information in memory results in improved performance over reading disk files each time a table is opened.
If your database is volatile, with many new tables being created or other tables deleted, you may not want to use the table name cache file because the mapping between database tables and data dictionaries will not stay in force.
If there has been change to the table structure of your DSN, you must recreate the cache file. Delete the existing file, which resides in the XFD directory, and make sure that the Table Name Cache check box is selected so that a new "all-tabs.dir" file is created the next time you connect to the data source.
COBOL does not have a concept that corresponds directly to SQL's NULL. The closest candidates in COBOL are data items that contain either SPACES or LOW-VALUES. In SQL, NULL is often used for no data.
To maintain the integrity of the source data and to ensure that any data written from your application back to the COBOL source is accurate, you must provide a representational mapping between COBOL's SPACES and LOW-VALUES and the corresponding SQL column values. Use this control to indicate which COBOL data should be represented as NULL and how SQL NULLs should be translated into COBOL data.
For data coming in to your application (READs), if a field contains either SPACES or LOW-VALUES in alphanumeric data in the COBOL files, you can instruct the application to represent it as either NULL or an empty string. If a field contains either SPACES or LOW-VALUES in numeric data in the COBOL files, instruct the system to represent it as either a NULL or a zero.
Alphanumeric Input
AcuODBC follows these rules for alphanumeric data coming into an ODBC-enabled application.
| If an alphanumeric field contains ... | Then that field ... |
| All SPACES or all
LOW-VALUES | Comes into the application as either NULL or as an empty string, depending on the setting for variables for the data source on the Advanced tab of the AcuODBC Configuration property sheet. |
| Any other values | Comes into the application unchanged. |
Numeric Input
Numeric fields present a slightly more complicated scenario, because LOW-VALUES and SPACES are valid values for many numeric types, as shown in the following examples:
| If the numeric type is ... | LOW-VALUES is
equal to ... | SPACES is equal to ... |
| PIC 9(4) COMP-3 | 0 | 2020 |
| PIC 9(2) COMP-5 | 0 | 8192 |
| PIC 9(4) COMP-2 | 0 | INVALID |
Therefore, AcuODBC follows these rules for numeric data coming in to the ODBC-enabled application:
| If a field contains ... | And ... | Then ... |
| All LOW-VALUES | LOW-VALUES is an invalid value for the numeric type | The field comes into the application based on the setting for numeric variables for the data source on the Advanced tab of the AcuODBC Configuration property sheet. |
| All SPACES | SPACES is an invalid value for the numeric type | The field comes into the application based on the setting for numeric variables for the data source on the Advanced tab of the AcuODBC Configuration property sheet. |
| Any other values | The value is invalid for the numeric type | Undefined data may come in to the application |
The following table shows the default settings:
 | On Input
(to your ODBC-enabled application) | On Output
(to the COBOL source) |
| Alphanumeric | NULL | Spaces |
| Numeric | Zero | Zero |
A Julian date is the number of days since a certain date (the base date). For example, if the Julian base date is June 18, 2000 and today's date is July 4, 2000, the Julian date is 16. The default Julian base date in AcuODBC is January 1, 1900.
To specify the date from which to start counting Julian dates:
1. Select the component (month, day, or year) in the date field you wish to change. Note that you cannot select the day of the week.
2. Use the spin box at the right of the field to move the value of the component either forward or backward. The day of the week changes to match the new date.
You may also type a new date.
| October 30 | Julian date 0 |
| October 31 | Julian date 1 |
| November 1 | Julian date 2 |
| November 2 | Julian date 3 |
| November 3 | Julian date 4 |
Reset Configuration
Select Enable Reset to return to AcuODBC's configuration defaults, and then click Reset for confirmation. Any changes you had made to the configuration property sheet are erased.