WaveCrest
CView ODBC
User's Guide
Release 1.1
- Introduction
- Installation
- Data Dictionary Compiler
- Data Dictionary Decompiler
- Data Sources
- Fatal Errors
The WaveCrest CView product is designed to provide ODBC support to native CADOL files. There are several types of CADOL files in use today. These include CPS CDF, CtC C-ISAM, and VERSYSS CFAM. CDF files can reside on WIN32, SCO UNIX, and IBM AIX. CtC files can reside on the same platforms as CDF. CFAM files can reside on IBM AIX and SCO UNIX.
UNIX platforms are supported via a TCP/IP client/server interface, while WIN32 platforms are supported by a direct I/O or network interface.
The ODBC Driver product presents CADOL data to 3rd Party applications as though it were a Relational Database. Applications can access the data using SQL via the ODBC API.
The CView software uses a data dictionary to locate the data within your files. A sample data dictionary is provided with the system. The sample dictionary is named ‘dict.txt’ (on Windows installations this file exists in the CView bin directory). Instructions for adding your files to the data dictionary are given below. Once you have created and installed the data dictionary for your files you will be able to access them through your ODBC applications.
The CView software is provided for several different hardware and software platforms. Installation instructions follow for each of the available platforms, select the instructions below which are applicable to your installation.
Windows CDF Installation Instructions
To install the CView CDF ODBC Driver on your Windows system.
- Insert the Setup diskette into your A drive.
- Select Run from the start menu to run A:\setup.exe
- The introduction screen will be displayed, press <next> to continue.
- The CView directory selection screen will be displayed, normally you will press <next> to use the default folder.
- The confirmation screen will now display, press <next> to begin the installation.
- The install program will now install the CView CDF files.
- Once the files have been installed you will be asked for your WaveCrest Sales Order number delivered with the software. Enter this number and press <Enter>.
- Your license number will now be displayed and the authorization number will be asked for. Contact your CView distributor for an authorization number. You will be asked for your license number and will be given an authorization number.
- NOTE: The license and authorization numbers are unique for your machine and should be saved for later use if you need to reinstall the software on this machine.
- The installation software will now license the software for you, when it is finished it will say "The product has been successfully licensed."
- The completion screen will now display. Press <Finish> to exit the setup program.
The installation software will create several directories on your system. The CView ‘bin’ directory contains the ODBC development binaries, the ‘sysvol’ directory contains the ODBC configuration and system files. For CDF installations, the odbctest directory contains sample data files.
Windows Client Installation Instructions
To install the CView Client ODBC Driver on your Windows system.
- Insert the Setup diskette into your A drive.
- Select Run from the start menu to run A:\setup.exe
- The introduction screen will be displayed, press <next> to continue.
- The CView directory selection screen will be displayed, normally you will press <next> to use the default folder.
- The confirmation screen will now display, press <next> to begin the installation.
- The install program will now install the CView Client files.
- Once the files have been installed you will be asked for your Server Host Name and TCP/IP address. You can get this information from your system administrator. Enter the host name and address and press <OK>.
- The system will add your host to the \windows\hosts file and the cviewsrv service to the \windows\services file.
- The completion screen will now display. Press <Finish> to exit the setup program.
The installation software will create several directories on your system. The CView ‘bin’ directory contains the ODBC development binaries, the ‘sysvol’ directory contains the ODBC configuration and system files. For CDF installations, the odbctest directory contains sample data files.
During installation the system will modify the \windows\hosts and \windows\services files on your system. The \windows\hosts file contains a list of all hosts known to the system and their IP addresses. It is used by the CView client to obtain the IP address for the CView server host. The \windows\services file contains a list of known services and their port numbers. The CView client obtains the port number for the cviewsrv server from this file.
UNIX CFAM Server Installation Instructions
To install the Cview CFAM server on your UNIX system.
- Log in as root.
- Copy the ‘cfamsrv.tar.Z’ file from the CView server media into the /tmp directory.
- Move to the tmp directory by typing ‘cd /tmp’.
- Uncompress the file by typing ‘uncompress cfamsrv.tar.Z’
- Install the CView server software on your system by typing ‘tar xvf cfamsrv.tar’. This will create a \cview directory and will copy the server files into it.
- Move to the cview bin directory by typing ‘cd /cview/bin’.
- Install the server by typing ‘./install’.
- The install script will add the Cview server to your system by modifying the ‘/etc/inetd.conf’ and ‘/etc/services’ files.
- The installation software will ask you whether to license the software at this time. The CView server will not operate until it has been licensed. If you choose not to license the server at this time you can license it later by logging in as root and running the /cview/license program.
- The license manager will ask you for your WaveCrest Sales Order number delivered with the software. Enter this number and press <Enter>.
- Your server license number will now be displayed and the server authorization number will be asked for. Contact your CView distributor for an authorization number. You will be asked for your server license number and will be given a server authorization number.
- Enter the authorization number and press <Enter>.
- The license program will now finish the licensing process. Write down your authorization number and keep it in a safe place. If you need to reinstall your CView server on this machine you will need your authorization number.
The CView server installation program installs the server at socket port 29999 of your UNIX system. If you should need to change this port number, edit your ‘/etc/services’ file and change the port number. You will also need to change the port number in the ‘\windows\services file on your client machines.
The CView license manager licenses the CView software. The license manager asks for your WaveCrest sales order number and generates a license number which is unique for your machine. It then asks for an authorization number. You can obtain your authorization number from your CView distributor. The license and authorization numbers are unique for your machine and should be saved for later use if you need to reinstall the software on this machine.
- UNIX: Log in as root and move to the CView bin directory by typing ‘cd /cview/bin’.
- Windows: Start an MS_DOS job and move to the cview bin directory.
- UNIX: Run the license program by typing ‘./license’.
- Windows: Run the license program by typing ‘.\license’.
- The license manager will ask you for your WaveCrest Sales Order number delivered with the software. Enter this number and press <Enter>.
- Your server license number will now be displayed and the server authorization number will be asked for. Contact your CView distributor for an authorization number. You will be asked for your server license number and will be given a server authorization number.
- Enter the authorization number and press <Enter>.
- The license program will now finish the licensing process. Write down your authorization number and keep it in a safe place. If you need to reinstall your CView server on this machine you will need your authorization number.
Once you have installed the CView driver you can change it’s configuration using the ODBC Administrator from the Windows Control Panel. To start the ODBC administrator, open the control panel from the Settings selection of the Start menu and double click on the ‘32bit ODBC’ icon. This will display a list of all defined ODBC sources on your system. To change the CView configuration select the CView driver from the list by clicking on it and press the configure button.
The configuration window will display the driver name, description, database path, and trace flag. Do not change the driver name or description fields. You can change the database path field to cause the driver to use a different path for the database.
The final field in the configuration window is the trace flag. On installation this flag is set to 0. If you need to trace the execution of the driver you can set this flag to 1. This will cause the driver to write extensive trace information to a file in the Windows\temp directory named dblog.log. This can be useful in determining the cause of a problem.
NOTE: You should never leave the trace flag set. It will slow down the driver and will use up disk space with the dblog.log file. Once you have completed tracing, you should set the flag back to 0.
The CView installation program installs a configuration file named ‘devices.cfg’ into the sysvol directory. The configuration file is used by the CView driver for information about the server host name and/or the path’s to data volumes. The configuration file can be edited with any text editor such as Notepad. When you open the devices.cfg file you will see the configuration entries.
For example:
SERV_HOST: aix
DRIVE: 0 C:
DRIVE: 1 D:
# DEFINE VOLUME PATHS
# volume name line must be in the following format:
# it must begin with the string 'VOL:name' where name is the volume name
# (maximum name length is 8 characters), this is followed by one or more
# spaces and the volume path name.
#
# ex: to map volume 'TESTVOL' to path '/usr/yourdir'
# VOL:TESTVOL /usr/yourdir
VOL:sysvol /cview/wccdf/sysvol
VOL:/SYSVOL /cview/wccdf/sysvol
VOL:TEST /cview/wccdf/odbctest
The example above identifies a server host system, two drive identifiers, and three volumes.
The first entry in the configuration file is the SERV_HOST entry. This entry is only used by CView clients. If you are not using a CView client this entry will not be used. The SERV_HOST entry is used to define the name of the host system which the CView server resides on. In the example above, the host system is named ‘aix’.
The next entry type in the configuration file is the DRIVE entry. This entry is only used by CView CDF drivers. The DRIVE entry is used to map a CADOL drive number to a physical path. The path can contain a drive identifier followed by an optional directory path. Drive path’s are used in determining the location of a data file. If you do not specify a drive path in you data definition the system will use drive 0 as the default drive.
The last entry type is the VOL entry. This entry is only used by CView CDF drivers. The VOL entry is used to map a CADOL volume name to a directory. In the example above there are three volumes defined. The first two volumes point to the same directory while the third points to a separate directory named ‘odbctest’.
If you are using the CView CDF driver, you must define the volumes in which your data is kept before you will be able to access the data. The CView client driver does not require the volume information to be defined.
The CADOL application files are defined through a data definition language. The data definition is created in a standard text file using a text editor. Once the definition is complete, it is compiled using the dictionary compiler to create a binary dictionary file.
The compiler is invoked from a command prompt as
ddc <dictionary source file> </M>
Where the </M> argument is optional. The /M argument causes the compiler output to be piped through the "more" command to pause output a screen at a time.
The compiler prints the dictionary source tokens as it compiles. It prints any errors found during the compilation of the dictionary file. If errors are detected then the binary dictionary file will not be created. If there are not errors in the dictionary source file then a dictionary binary file will be created with the name defs.dcc. Before creating the new dictionary binary file the compiler tests for the existence of an existing defs.dcc file. If one is found, then it is renamed by appending a ‘.xx’ suffix to it, where ‘xx’ is a two digit, zero filled number. The number will always start at zero and will be incremented until a unique file name is found. If there are one hundred copies of the file with suffixes ‘.00’ through ‘.99’ then no file will be created and an error will be output.
If the dictionary was not compiled in the destination server directory then it must be copied there before starting the driver.
The data dictionary is created through the use of a data definition language. Like any programming language the data definition language (or DLL) has specific constructs and language syntax which are used to specify the target files. The DLL provides for the definition of the legacy files and record layouts.
In addition to the syntax described below, all UNIX ‘cpp’ preprocessor syntax is allowed. This provides for macro definition as well as #ifdef logic. By the use of the ‘cpp’ #include command each CADOL file definition can be kept in a separate text file.
NOTE: The preprocessor commands must be in lower case.
As you read through the language definition you can see that the language defines files and SQL tables. A CADOL file definition includes one or more CADOL record definitions. A CADOL record definition identifies the CADOL record layout and maps the record to a SQL table. A CADOL record definition incorporates a SQL table definition, a CADOL record type definition, and a CADOL record layout definition.
The dictionary supports many methods of determining the CADOL record type. Record types can be determined by KEY, REC, or field or string subfield comparisons, by testing the length of string fields or the key, and other tests. Fields can be tested for a range of values. Multiple tests are supported, substrings are supported, and strings can be tested using a powerful pattern matching syntax.
A record type specification consists of a one or two character identifier for the record type and a WHERE clause which describes the conditions which identify the record type. A WHERE clause can specify multiple conditions via AND and OR logic. Each condition can test a string, number, or byte sequence. If there are multiple record types in a file the record WHERE tests are performed in record type identifier order. For example, a record type of ‘A’ will be tested before a record type of ‘B’.
A string can be a CADOL KEY or a string field with an optional field skip clause to identify how to find the string in the record. A string clause lets you test a substring of a string. A skip clause allows the user to specify the list of alpha and numeric fields up to the target field. The system uses the skip clause to test all records, therefore the skip clause should only define fields common to all records in the file.
A number can be a numeric field (with an optional skip statement), REC, or the length of a string.
A byte clause tests a sequence of bytes starting at a given offset in the buffer against a hex value.
A string, number, or byte can be tested for equal, not equal, less than, or greater than. A string condition is tested against a UNIX regular expression. A regular expression can define a pattern to match. A string can only be tested against a regular expression for the equal or not equal operators. If the less than or greater than operators are used then the compare string is assumed to be a string constant rather than a regular expression.
CADOL fields are presented to 3rd party applications as SQL columns. Each CADOL field (or substring field) is given a SQL column name and data type.
The dictionary can define data conversion for CADOL data fields. The ODBC driver automatically converts from the CADOL type to the SQL type as defined in the dictionary.
String fields or string subfields can have one of three string functions applied to the field. A substring can be identified by a starting position and a length or by searching for a delimiter within the string. Strings can be converted to upper case, lower case, or have the first character upper case and the rest lower case. Strings can be converted to dates using a date format mask. Strings can be converted to times using a time format mask. Strings can be converted to numbers through the use of a numeric format mask.
Numeric fields can be converted to floating point numbers or strings through the use of a display format. They can be converted to a date using a date format mask. Numeric fields can be converted to times using a time format mask.
The dictionary defines a file at a time. File definitions need not be in any specific order.
Use the FILE command to identify the start of a file definition and the ENDFILE command to identify the end of the file definition.
Syntax:
FILE DEVICE devno VOLUME volid NAME fileid KEYLEN keylen
ENDFILE
A file will contain one or more record definitions. Record definitions need not be in any specific order.
Use the RECORD command to identify the start of a record definition and the ENDRECORD command to identify the end of the record definition.
Syntax:
Field Definitions
ENDRECORD
The tableid field is a unique SQL table identifier. SQL table names can be up to twenty characters and are not case sensitive. Each table name must be unique within the dictionary.
A record definition can contain a record type and associated record matching definition or can be a default record type with no record matching logic required. If a file contains a single record type then it will only contain a default record.
If a file contains multiple record types then it will contain a record definition for each record type. A record definition in a multi-record type file contains a record type id and a where logic clause which determines how to identify this record type. One and only one of the record definitions can be identified as the default record which is used if all other matches fail.
The rectypeid field is a one or two character identifier for the CADOL record type. The record identifier is used to determine the sequence of record type comparisons within a table. In determining a record type the system will use the lowest valued record type identifier first and check each record type in order until a match is found.
Example:
FILE VOLUME TEST NAME CUST KEYLEN 8
RECORD TABLE CUSTNAME DEFAULT
field definitions
ENDRECORD
RECORD TABLE CUSTADDR B WHERE NUMERIC 1 = 2
field definitions
ENDRECORD
RECORD TABLE CUSTDEPT A WHERE KEY(1,1) = 'D' AND NUMERIC 1 = 2
field definitions
ENDRECORD
ENDFILE
In the example above the CUST file is defined. The CUST file contains three different record types. The record types are defined as SQL table names CUSTNAME, CUSTADDR, and CUSTDEPT. The CUSTDEPT record is determined by the first numeric byte of the record having the value of 2 and the first character of the KEY having the value ‘D’. The CUSTADDR record is determined by having the first byte of the record having the value of 2. If the record is not a CUSTDEPT record or a CUSTADDR record then it is a CUSTNAME record. Notice that the CUSTDEPT record was given a record type of A while the CUSTADDR record was given a record type of B. This tells the system to check for a CUSTDEPT record before checking for a CUSTADDR record. If the record types were reversed the system would identify CUSTDEPT records as CUSTADDR records because they both have a NUMERIC 1 field value of 2. The CUSTDEPT record needs to check for this field value but must also match the KEY(1,1) value to ‘D’. The record type field can be used to specify the order in which record definitions are to be checked.
To determine the type of the record a WHERE clause is used. The WHERE clause allows the specification of one or more comparisons of data within the record.
Syntax:
WHERE fieldtype comparison value [AND | OR fieldtype comparison value …]
A WHERE clause contains one or more comparisons. Each comparison contains a fieldtype identifying the data to compare, a comparison operator, and a value to compare against. Multiple comparisons can be used for complex record matches. Parentheses can be used to logically group comparisons.
The fieldtype in a comparison can identify a string, numeric, or byte comparison. The possible values for the fieldtype are STRING, KEY, NUMERIC, LENGTH, REC, and BYTE. A string comparison identifies a string field or subfield to compare, the KEY is considered a string field. A numeric comparison identifies a numeric field to compare. A numeric field can be a field within the record, the REC value, or the length of a string field. A byte comparison is used to compare a sequence of bytes within the record against a hexadecimal value.
String Comparisons
A string comparison is used to match a string value against a pattern. A string value is either a string field or KEY, or a sub-field of a string field or KEY. The pattern is defined using the UNIX regular expression syntax. This is a powerful pattern matching syntax which can be used to match many different string formats.
Syntax:
{KEY [(start,end)] | {STRING [(start,end)] [SKIP A | Nx , …]}} operator expression
If comparing a string field you can define the fields to skip to reach the
target field with a skip statement.
The skip statement consists of SKIP followed by a comma separated series of A’s
or N’s followed by the number of bytes to skip. The system uses the skip
clause to test all records, therefore the skip clause should only define fields
common to all records in the file.
The operator in a string comparison is one of the <, >, =, or # operators.
The expression is any regular expression including a string constant.
Numeric Comparisons
A numeric comparison is used to match a numeric value against a constant. A numeric value is either a numeric field, LENGTH of a string, or REC.
Syntax:
{REC | {NUMERIC [SKIP A | Nx , …]} | LENGTH string }operator numeric constant
If comparing a numeric field you can define the fields to skip to reach the
target field with a skip statement.
The skip statement consists of SKIP followed by a comma separated series of A’s
or N’s followed by the number of bytes to skip. The system uses the skip
clause to test all records, therefore the skip clause should only define fields
common to all records in the file.
The operator in a numeric comparison is one of the <, >, =, or # operators.
The length of a string field can be tested. To test the length of a string use LENGTH followed by any string statement as described above in string comparisons.
Byte Comparisons
A byte comparison is used to match a sequence of bytes in the record against a hexadecimal constant.
Syntax:
BYTE (start,length) operator hex value
A byte comparison identifies the starting byte in the record and the number of bytes to compare.
The operator is one of the <, >, =, or # operators.
The hex value is a series of two character hexadecimal digits to compare against.
Once you have defined a record type and how to determine the record type you define the fields in that record type.
Syntax:
FIELDS fieldstmts ENDFIELDS
Fields must be defined in the order that they appear in the record. Each field definition consists of the CADOL field type, followed by the SQL name you want to give the field, followed by the SQL data type for the field.
If you have a record type which you don’t want to define the fields for and not access using ODBC you can define the record as a packed or native CADOL type with the PACKED keyword.
Example:
FIELDS PACKED ENDFIELDS
When defining fields you describe the CADOL field and then assign a SQL definition to the field. The SQL definition includes a name for the field, a data type, and possible conversion information. Field names can be up to twenty characters long and must start with a letter.
CADOL fields are either string fields or numeric fields consisting of one to six bytes. To define a string field use the STR keyword. To define a numeric field use the NUMERIC N keyword where N is the number of bytes for the field.
Example:
STR CUST_NAME STRING 20
NUM 3 BALANCE DOUBLE (7.2)
In the example above we are defining two fields. A string field called CUST_NAME and a numeric field called BALANCE. The CUST_NAME field has a maximum length of 20 characters and the BALANCE field is converted to a double precision field with two digits to the right of the decimal point.
SQL Data Types
The system supports the following SQL data types:
LONG, SHORT, DOUBLE, DATE, TIME, CHAR
The LONG and SHORT types are long and short integers. The DOUBLE type is a floating point double precision number. The DATE and TIME types are SQL date and time values. The CHAR type is a SQL varchar type.
A CADOL field can be defined as any of the supported SQL data types. You can apply conversion functions to each field to convert it from the CADOL type to the SQL data type.
CADOL String Field Definitions
CADOL string fields are normally defined as SQL string fields, but some applications use string fields as date, time or numeric fields. Using the dictionary you can define a string field as any SQL type and the system will automatically convert the data for you at runtime. You can also divide a CADOL string field into multiple SQL fields using the sub-string functions.
Syntax:
STR [substring def] sql-name sql-type
Sub Strings
Sometimes you may want to divide a CADOL string field into multiple SQL fields. A common example of this is to divide a name into first and last name fields. To divide a string into multiple fields, use a substring definition. You can specify a string field by an index (start,length) or by searching for a specific character using the STRSTR function.
Example:
STR (1,5) CUST_TYPE STRING 5
STR (6,5) INV_TYPE STRING 5
STR STRSTR(1,",") FIRST_NAME STRING 20
STR STRSTR(2,",") LAST_NAME STRING 20
When using an index (start,length) you specify the starting character in the string where the first byte is 1 and the number of characters in the string. When you need to search for a specific string or character to delimit the fields use the STRSTR function. STRSTR(occurrence, search_string) returns the substring from the nth occurrence-1 of the search string to the nth occurrence and strips the search_string from the resulting field. For example STRSTR(1,",") returns from the start of the string to the character before the first comma, while STRSTR(2,",") returns from the character following the first comma to the character before the second comma (or the end of the string).
String Conversions
String fields can have a conversion function applied to them to force the characters to a specific case.
Example:
STR FIRST_NAME STRING 20 FCASE
STR TYPE STRING 2 LOWER
STR TYPE_2 STRING 2 UPPER
The FCASE function converts the first character in each space delimited word to upper case and the remaining characters to lower case. The LOWER function converts all characters in the string to lower case and the UPPER function converts all characters in the string to upper case.
To convert a string to another SQL data type you must specify a conversion mask. To convert string fields to numeric fields use a mask in the form of (int.fpt), where int is the number of digits in the integer part of the field and fpt is the number of digits in the fractional part of the field.
Example:
STR COUNT LONG (7)
STR BALANCE DOUBLE (7.2)
The COUNT field is converted to a LONG type by taking up to seven digit characters from the string. The BALANCE field is converted to a DOUBLE type by taking up to seven digit characters, a decimal point, and up to two digit characters.
Strings can also be converted to DATE or TIME fields. The mask for a date field consists of the CYMD ’/’ and ‘-‘ characters. The C character specifies the century, Y the year, M the month, D the date, and the ‘/’ and ‘-‘ characters are delimiters. The mask for a time field consists of the HMS ‘.’ and ‘:’ characters. The H character specifies the hour, M the minute, S the seconds, and the ‘.’ and ‘:’ characters are delimiters.
Example:
STR INV_DATE DATE M/D/Y
STR INV_TIME TIME H.M.S
STR PMT_DATE DATE CYMD
The example above defines two date fields and a time field.
CADOL Numeric Field Definitions
CADOL numeric fields are normally defined as SQL numeric fields, but some applications use numeric fields as date, time or string fields. Using the dictionary you can define a numeric field as any SQL type and the system will automatically convert the data for you at runtime.
Syntax:
NUM length sql-name sql-type
When defining a numeric field you must always specify a conversion mask. The example below shows numeric fields converted to all of the possible data types.
Example:
NUM 1 TYPE SHORT (1)
NUM 3 COUNT LONG (7)
NUM 6 BALANCE DOUBLE (7.2)
NUM 3 CUST_ID STRING 6 (6)
NUM 3 START_DATE DATE YMD
NUM 3 END_DATE DATE JULIAN
NUM 3 START_TIME HMS
When converting to date fields you can specify a mask using the CYMD characters or define it as a Julian date using JULIAN. When converting to time fields you can specify a mask using the HMS characters.
SQL Numeric Data Types
SQL provides a number of different numeric data types, here is a list of the numeric data types supported by the CView product and the valid range for each type. When defining your numeric fields you should choose a numeric type which can hold the largest possible value of the field. If the field contains an implicit decimal point then the SQL DOUBLE type should be used.
|
CADOL FIELD |
SQL TYPE |
VALUE RANGE |
|
1 Byte Integer |
SHORT INTEGER |
+- 32767 |
|
2-4 Byte Integer |
LONG INTEGER |
+-2147483647 |
|
5-6 Byte Integer |
DOUBLE |
1.7976931348623158e+308 |
|
Real Number (w/ decimal point) |
DOUBLE |
1.7976931348623158e+308 |
To enable an existing data definition to be examined, a data decompiler is provided. This program creates a text form of a dictionary definition from a binary dictionary file.
The decompiler is invoked from a command prompt as
ddcdump <dictionary binary file>
The decompiler reads the given binary file and prints the dictionary source on the standard output. This can be redirected to a text file through the standard UNIX or NT redirection symbols.
To decompile the defs.ddc dictionary and save the output in the file OldDef.txt type the following:
ddcdump defs.ddc > OldDef.txt
The CView Driver reads the dictionary and host/volume definitions from the sysvol directory. The combination of the dictionary definitions in the defs.ddc file, and the configuration defintions in the devices.cfg file make up a CView Data Source. When the CView Driver is installed, it installs a Data Source named ‘CView CDF Data’ or ‘CView Client Data’, depending on the type of driver you are using. The path to the Data Source is defined as ‘\CVIEW\WCCDF’ or ‘\CVIEW\CLIENT’. You can see the Data Source path by using the CView configuration utility.
To examine the current configuration select ‘Settings’ and ‘Control Panel’ from the Start Menu. Now double click on the ‘ODBC Administrator’ icon. Select the CView Data Source from the list of defined ODBC Data Sources and press the Configure button. The CView Driver configuration window will display and the Data Source path is shown in the ‘Database Path’ field.
At times you will want to provide access to more than one data source. You may have different dictionaries, or may have data which repeats for multiple entities. An example of this is a multi-store environment. The volume names and data files are the same for each store. The volumes are mapped to different directories in the devices.cfg file. This could be set up where each store is a different Data Source.
To establish a new Data Source for the CView driver, follow these steps:
- Create a directory for the data source. To keep your data organized it is a good idea to create this directory under the /CVIEW directory.
- Copy the CView sysvol directory and it’s contents to the new directory.
- Edit the devices.cfg file in the new directory to reflect the new volume path’s or host name.
- If the new Data Source has a different dictionary then create the new defs.ddc and copy it into the new sysvol directory.
- Start the ODBC Administrator utility from the control panel, make sure the the User DSN tab is the current tab.
- Press the Add button to add a Data Source.
- The existing ODBC drivers will be displayed, select the CView driver and press the Finish button.
- The CView configuration window will display, enter a new name for your Data Source.
- Enter the path to your new Data Source. This will be the path to the directory you created in step 1.
- Enter 0 in the Driver Trace field to disable tracing.
- Press the OK button. You have now defined your new Data Source.
Once you have defined a new Data Source, you will be able to select it from the existing ODBC Data Sources within your application.
If the CView driver encounters a fatal error during processing it will write an error message to the log file and exit. This will cause the application using the driver to exit also. If your application exits without any message then you should look in the Windows\temp directory for a file named ‘dblog.log’. Open this file with an editor such as Notepad to see the error message.
This section lists the possible fatal error messages for the CView driver. The error messages are found in the ‘dblog.log’ file after the driver encounters the error.
Any message in this group means that the dictionary is corrupt. You should check the definition and recompile.
- Table.GetColumn: Invalid Column Type
- Table.GetColumn: Invalid Column SQLType
- Invalid Field Type <type> for field '<field name>'.
- Invalid Field SQL Type '<type>' for field '<field name>'
- NULL field found in Definition.
- Invalid field type encountered during Extract
- ExtractString: Invalid data type encountered.
- ExtractNumeric: Invalid data type encountered.
- Table.WhereExpr: Invalid Where Expression
- Table.where_evaluate: Invalid where source type.
- Table.str_where_evaluate: Invalid where comparison type.
- Table.where_skip: Invalid skip clause.
- Table.num_where_evaluate: Invalid where comparison type.
- Table.byte_where_evaluate: Invalid where comparison type.
- Invalid object type in dictionary.
These errors are caused by entering an invalid date or time format in the dictionary. Correct the dictionary and recompile.
- str_sqldate(): Invalid date format.
- str_sqltime(): Invalid time format.
The final error is caused by a data definition which does not match the data in the file. Correct the dictionary and recompile.
- Could not extract field <field name>
If the field identified in the error is a string field, then one of the following is true.
String is shorter than defined substring.
Substring search string is not found in the string.
Invalid time found in string conversion.
If the field identified in the error is a numeric field, then one of the following is true.
A numeric to string conversion is longer than the defined string.
Invalid time found in numeric conversion.
©2002 WaveCrest Software, Inc