SP Linking with SuperLib

 Linking with either RTLINK or BLINKER is fairly
 painless. (OR EXOSPACE FOR 5.3)

 For RTLINK I use:

     RTLINK FI <file> LIB SUPER35

 For BLINKER I use

     BLINKER FI <file> ALLOCATE SUPER35

 For EXOSPACE (5.3) I use

     EXOSPACE FI <file> LIB SUPER35

 Of course you may also use a link file.

 

Advertisements

C5DG-9 Terminal Drivers

Clipper 5.x – Drivers Guide

Chapter 9

Alternate Terminal Drivers

Clipper supports a driver architecture that allows Clipper- compiled applications to use alternate terminal drivers. This architecture provides support for nonstandard video hardware and ANSI output devices, allowing your applications to run in a wider variety of environments.

The following terminal drivers are supplied as part of the Clipper Development System and are discussed in this chapter:

. The ANSITERM driver provides ANSI terminal support for systems that require it

. The NOVTERM driver causes Clipper applications to execute faster when run on some nondedicated network server software

. The PCBIOS driver provides direct BIOS calls rather than direct screen writes for systems requiring this form of I/O

In This Chapter

This chapter discusses how Alternate Terminal Drivers fit into the overall Clipper architecture as well as how to install and use each of the supplied terminal drivers. The following major topics are discussed:

. The Alternate Terminal Driver Architecture

. The ANSITERM Alternate Terminal Driver

. The NOVTERM Alternate Terminal Driver

. The PCBIOS Alternate Terminal Driver

The Alternate Terminal Driver Architecture

In Clipper, communication with I/O devices is controlled by a multilayered terminal system. At the lowest level is the terminal driver which controls screen and keyboard activity. It consists of a screen and keyboard driver that communicates directly with the I/O device (operating system or hardware). It is the device specific part of the Clipper terminal system.

There is, then, a higher level system that communicates with terminal drivers. This system is known as the General Terminal (GT) system and provides general services that create Clipper screen and keyboard commands and functions. The following figure demonstrates:

                   +—————————————–+

                   | CA-Clipper screen and keyboard commands |
                   |              and functions              |
                   |-----------------------------------------|
                   |        General Terminal (GT.OBJ)        |
                   ------------------------------------------|
                   |             Terminal Driver             |
                   |-----------------------------------------|
                   |          Screen   |   Keyboard          |
                   +-----------------------------------------+

The default terminal driver, designed for IBM PC and 100% compatibles, is supplied as a library file (TERMINAL.LIB) installed into your \CLIPPER5\LIB directory. This driver links into each program automatically if you specify no alternative terminal driver provided that you do not use the /R option when you compile. An alternate terminal driver is supplied as a separate library (.LIB) file that links into an application program in place of the default terminal driver if you specify it on the link line.

All alternate terminal drivers work through the General Terminal layer as supplied in the file GT.OBJ. The Clipper installation program installs this file in the \CLIPPER5\OBJ subdirectory on the drive that you specify, so you need not install the driver manually.

The ANSITERM Alternate Terminal Driver

The ANSITERM terminal driver supports the ANSI screen mode for all screen display from Clipper programs.

This screen mode is installed by specifying ANSI.SYS in the user’s CONFIG.SYS. ANSI.SYS replaces the default DOS CON device driver for video display and keyboard input. Once installed it supports ANSI escape sequences to erase the screen, set the screen mode, and control the cursor in a hardware-independent way. Most modern DOS programs, however, do not use it and write either directly to the video hardware or use BIOS routines for enhanced screen performance.

Use the ANSI screen mode for Clipper programs that run on hardware that does not support either writing to video hardware or BIOS calls for screen display. This is the case when using alternative display hardware to support the blind.

Note: The ANSITERM terminal driver fully supports all screen and keyboard functionality of the default terminal driver. This includes the ability to save and restore screens and support for all keys on the standard 101-key keyboard.

Installing ANSITERM Terminal Files

The ANSITERM terminal driver is supplied as the file ANSITERM.LIB. The Clipper installation program installs this file in the \CLIPPER5\LIB subdirectory on the drive that you specify, so you need not install it manually.

Linking the ANSITERM Terminal Driver

To link the ANSITERM alternate terminal driver into an application program, you must specify both GT.OBJ and ANSITERM.LIB to the linker along with your application object (.OBJ) modules.

1. To link with .RTLink using positional syntax:

C>RTLINK <appObjectList> GT,,, ANSITERM

2. To link with .RTLink using freeformat syntax:

C>RTLINK FI <appObjectList>, GT LIB ANSITERM

3. To link with .RTLink using ANSITERM.PLL and freeformat syntax:

C>RTLINK FI <appObjectList> /PLL:ANSITERM

Note: These link commands assume you have set the LIB, OBJ, and PLL environment variables to the standard locations. They also assume that the Clipper programs were compiled without the /R option.

Important! You cannot link the ANSITERM driver with BASE52.PLL. An application linked with both ANSITERM.LIB and BASE52.PLL may cause the computer to freeze upon execution.

The Runtime Environment

Using ANSITERM.LIB requires that ANSI.SYS be installed on the user’s computer. To accomplish this, include the following statement in the user’s CONFIG.SYS:

DEVICE=ANSI.SYS

Performance Concerns

Because the ANSITERM terminal driver uses buffered screen writes for all screen painting, some operations, especially those that scroll the screen, are slow. These include:

1. All box drawing commands and functions

2. All console commands and functions when scrolling

3. All clear screen commands and functions

4. All restore screen commands and functions

5. Standard out functions (OUTSTD() and OUTERR()) whether the screen is scrolling or not

Note: Overall performance of Clipper programs is slower since the ANSITERM terminal driver must spend more time polling for user events than the standard Clipper terminal driver.

Screen Output from C and Assembly Language

The ANSITERM terminal driver overwrites all output from C and Assembly Language when it refreshes the screen from the screen buffer. As a consequence, you should perform all screen output from Clipper.

The ANSITERM terminal driver also virtualizes the cursor. This means that BIOS functions that report the location of the hardware cursor will not always return the correct value. To obtain the cursor position, use Clipper’s ROW() and COL() functions instead.

Other Incompatibilities

1. ISCOLOR() always returns false (.F.).

2. When you load DBU, the default color mode is monochrome unless you specify DBU with the /C command line option.

3. The first time you invoke the Debugger, the default color mode is also monochrome unless you set the Options:Mono display off.

4. When an application linked with the ANSITERM terminal driver terminates, the last color set in the application becomes the DOS color. This happens since colors set with ANSITERM are global to DOS and Clipper cannot query DOS for the current screen colors as the application loads.

5. Nondisplaying ASCII characters are presented as a space by the ANSITERM terminal driver. These include BELL (CHR(7)), BS (CHR(8)), TAB (CHR(9)), LF (CHR(10)), CR (CHR(13)), and ESC (CHR(27)).

The NOVTERM Alternate Terminal Driver

The NOVTERM terminal driver is a special-purpose driver that circumvents an incompatibility between some nondedicated network server software and Clipper. This incompatibility causes printers connected to the server to slow to an unusable rate.

Clipper applications and nondedicated servers compete for resources. Clipper applications make use of the time between keystrokes to perform various system tasks. This greatly improves the application’s overall performance by limiting its idle time. Certain nondedicated servers only attempt to print within an application’s idle time. Since a Clipper application is seldom idle, this greatly slows printing.

Important! The NOVTERM terminal driver corrects the incompatibility by preventing the Clipper application from using idle time. Because this can severely hamper performance, you should only use the NOVTERM terminal driver when necessary, and then you should link it only into those applications that are physically running the nondedicated server.

Note: The NOVTERM terminal driver fully supports all screen and keyboard functionality of the default terminal driver. This includes the ability to save and restore screens and support for all keys on the standard 101-key keyboard.

Installing NOVTERM Terminal Files

The NOVTERM terminal driver is supplied as the file NOVTERM.LIB. The Clipper installation program installs the driver file in the \CLIPPER5\LIB subdirectory on the drive that you specify, so you need not install it manually.

Linking the NOVTERM Terminal Driver

To link the NOVTERM alternate terminal driver into an application, you must specify both GT.OBJ and NOVTERM.LIB to the linker with your application object (.OBJ) modules.

1. To link with .RTLink using positional syntax:

C>RTLINK <appObjectList> GT,,, NOVTERM

2. To link with .RTLink using freeformat syntax:

C>RTLINK FI <appObjectList>, GT LIB NOVTERM

3. To link with .RTLink using NOVTERM.PLL and freeformat syntax:

C>RTLINK FI <appObjectList> /PLL:NOVTERM

Note: These link commands assume you have set the LIB, OBJ, and PLL environment variables to the standard locations. They also assume that the Clipper programs were compiled without the /R option.

Important! You cannot link the NOVTERM driver with BASE52.PLL. An application linked with both NOVTERM.LIB and BASE52.PLL may cause the computer to freeze upon execution.

Performance Concerns

Overall performance of Clipper programs is slower since the NOVTERM terminal driver must spend more time polling for user events than the standard Clipper terminal driver and since the program will not use its idle time for other tasks.

Screen Output from C and Assembly Language

The NOVTERM terminal driver overwrites all output from C and Assembly Language when it refreshes the screen from the screen buffer. Therefore, you should perform all screen output from Clipper.

The NOVTERM terminal driver also virtualizes the cursor. This means that BIOS functions that report the location of the hardware cursor will not always return the correct value. To obtain the cursor position, use Clipper’s ROW() and COL() functions.

The PCBIOS Alternate Terminal Driver

The PCBIOS terminal driver uses BIOS calls instead of direct screen writes. It is designedd for applications that trap BIOS calls to redirect output over telecommunication lines or to convert output to a form compatible with two-byte character sets.

Note: The PCBIOS terminal driver fully supports all screen and keyboard functionality of the default terminal driver. This includes the ability to save and restore screens and support for all keys on the standard 101-key keyboard.

Installing PCBIOS Terminal Files

The PCBIOS terminal driver is supplied as the file, PCBIOS.LIB. The Clipper installation program installs the driver file in the \CLIPPER5\LIB subdirectory on the drive that you specify, so you need not install it manually.

Linking the PCBIOS Terminal Driver

To link the PCBIOS alternate terminal driver into an application program, you must specify both GT.OBJ and PCBIOS.LIB to the linker in addition to your application object (.OBJ) modules.

1. To link with .RTLink using positional syntax:

   C>RTLINK <appObjectList> GT,,, PCBIOS;

2. To link with .RTLink using freeformat syntax:

   C>RTLINK FI <appObjectList>, GT LIB PCBIOS

3. To link with .RTLink using PCBIOS.PLL and freeformat syntax:

   C>RTLINK FI <appObjectList> /PLL:PCBIOS

Note: These link commands assume you have set the LIB, OBJ, and PLL environment variables to the standard locations. They also assume that the Clipper programs were compiled without the /R option.

Important! You cannot link the PCBIOS driver with BASE52.PLL. An application linked with both PCBIOS.LIB and BASE52.PLL may cause the user’s computer to freeze when the user executes it.

Performance Concerns

Because the PCBIOS terminal driver uses buffered screen writes for all screen painting, some operations, especially those that scroll the screen, are slow. These include:

1. All box drawing commands and functions

2. All console commands and functions when scrolling

3. All clear screen commands and functions

4. All restore screen commands and functions

5. Standard out functions (OUTSTD() and OUTERR()) whether the screen is scrolling or not

Screen Output from C and Assembly Language

The PCBIOS terminal driver also overwrites all output from C and Assembly Language when it refreshes the screen from the screen buffer. Therefore, you should perform all screen output from Clipper.

The PCBIOS terminal driver also virtualizes the cursor. This means that BIOS functions that report the location of the hardware cursor do not always return the correct value. To obtain the cursor position, use Clipper’s ROW() and COL() functions.

Summary

This chapter has introduced you to the Alternate Terminal Driver concept, giving you specific information on the architecture used to implement them in Clipper. Each of the alternate terminal drivers supplied with Clipper was discussed, including how to link and use it into your application and the implications of doing so.

C5DG-8 DBPX Driver

Clipper 5.x – Drivers Guide

Chapter 8

DBPX Driver Installation and Usage

DBPX is the Paradox 3.5 compatible RDD for Clipper. It connects to the low-level database management subsystem in the Clipper architecture. When you use the DBPX RDD, you add a number or features, including the ability to:

. Create access to and modify Paradox tables, records, and fields

. Create, select, and activate secondary indexes on Paradox tables

. Create and modify Paradox table structures, including primary index fields

. Use explicit record and file locks with concurrent execution of other Clipper applications

. Import Paradox tables directly into Clipper arrays

In This Chapter

This chapter explains how to install DBPX and how to use it in your applications. The following major topics are discussed:

. Overview of the DBPX RDD

. Installing DBPX Driver Files

. Linking the DBPX Driver

. Using the DBPX Driver

Overview of the DBPX RDD

The DBPX driver lets you create and maintain (.db), (.px), (.x??), and (.y??) files with features different from those supplied with the original DBFNTX driver and compatible with files created under Paradox 3.5. The new features are supplied in the form of several syntactical additions to database and indexing commands and functions. Specifically you can:

. Create tables that recognize the standard Clipper data types as well as Currency ($) and Short (S) numbers between -32,767 to +32,767

. Create equally efficient keyed and unkeyed tables

. Create, select, and activate secondary indexes on Paradox tables

The DBPX driver provides simple, seamless access to the Paradox database system. The Clipper application programmer who intends to access Paradox tables with the “VIA” clause need only include the RDD header file at compile time and make the appropriate libraries available at link time.

Paradox stores data in tables (known to Xbase developers as data files (.db)’s), consisting of fields and records. Unlike Xbase databases, a Paradox database refers to a group of files that are related to each other in some way, rather than to one file.

Also, Paradox employs the concept of companion files, known as objects, that are related to the table. Some examples of object files are report forms, indexes, and data entry forms. A table and its accompanying objects are referred to as a family.

It is easy to identify objects belonging to a particular family since they all have the same base filename and are distinguished by their extensions as shown in the table below.

Paradox File Descriptions
——————–  —————————————————
Extension         Object

.DB                       Table

.PX          Primary Index 
.X?? or Y??  Secondary Index
.F or F??    Data Entry Forms
.R or R??    Report Formats
.G or G??    Graph Specifications
.SET         Image Settings
.VAL         Field Validity Specifications
------------ ------------------------------------------------------------

The DBPX driver only deals with the table and index files (.db, .px, .x?? and y??) so only these files are discussed here.

Though Paradox tables are limited to 8 character filenames, each table can contain an unlimited number of records in files up to 256M in size. Paradox records in nonkeyed tables can be up to 4000 bytes each while keyed tables have a 1350 byte limitation. Each record can contain up to 255 fields of up to 255 characters each.

There are some field naming restrictions you must observe. Field names may:

. Although the Paradox file structure allows fields to be up to 25 characters long, since Clipper symbols can only be 10 characters, DBPX truncates the field name to 10 characters.

. The Paradox file structure allows embedded spaces in field names. Since this is illegal in Clipper, the DBPX driver converts spaces into underscores (_).

. Not be duplicated in the same table.

Also, most Paradox data types directly match data types in standard Xbase data files, with these differences:

. Paradox tables support both the Numeric (N) data type as well as a more specific Currency ($) data type. Both the N and $ data types can have 15 significant digits. Numeric types that exceed this length are rounded and stored as scientific notation. Also, DBPX supports the Short (S) data type to represent numbers between -32,767 and +32,767.

. The Alphanumeric field type allows all ASCII characters except embedded nulls (ASCII 0). The Alphanumeric type is identical to the Character (C) data type in Xbase. Paradox limits this field type to 255 characters.

. Paradox also supports a Date (D) field type, stored as a long integer. It can contain any value between January 1, 100 A.D. and December 31, 9999.

Installing DBPX Driver Files

The DBPX RDD is supplied as the file, DBPX.LIB:

The Clipper installation program installs this driver in the \CLIPPER5\LIB subdirectory on the drive that you specify, so you need not install the driver manually.

Linking the DBPX Database Driver

To link the DBPX driver, you must specify DBPX.LIB to the linker along with your application object (.OBJ) modules.

1. To link with .RTLink using positional syntax:

C>RTLINK <appObjectList> ,,,DBPX

2. To link with .RTLink using freeformat syntax:

C>RTLINK FI <appObjectList> LIB DBPX

Note: These link commands all assume the LIB, OBJ, and PLL environment variables are set to the standard locations. They also assume that the Clipper programs were compiled without the /R option.

Using the DBPX Database Driver

To use Paradox files in a Clipper program:

1. Place REQUEST DBPX at the top of each program file (.prg) that opens a database file using the DBPX driver.

2. Specify the VIA “DBPX” clause if you open the database file with the USE command.

-OR-

3. Specify “DBPX” for the <cDriver> argument if you open the database file with the DBUSEAREA() function.

-OR-

4. Use RDDSETDEFAULT( “DBPX” ) to set the default driver to DBPX.

Except in the case of REQUEST, the RDD name must be a literal character string or a variable. In all cases it is important that the driver name be spelled correctly using uppercase letters.

The following program fragments illustrate:

REQUEST DBPX 
. 
. 
. 
USE Customers INDEX Name, Address NEW VIA "DBPX"
-OR-
REQUEST DBPX RDDSETDEFAULT( "DBPX" )
.
. 
. 
. 
USE Customers INDEX Name, Address NEW

Index Management 

The greatest variation from the standard Xbase database design in Paradox tables is index management. As in other systems, Paradox indexes are an efficient method of dynamically sorting or locating specific data within a table without forcing a search of all data in that table. Paradox tables take two forms: unkeyed and keyed.

An unkeyed table has no fields in its structure that have been identified as specific index keys. Therefore, records are maintained in natural order. New records are added to the end of an existing table, and the unique identity for each record is a record number.

Unlike Xbase data files, unkeyed tables are not more efficient in design or faster to traverse than keyed tables. This is because Paradox tables are built as linked lists rather than fixed-length, sequential tables. Therefore, it is actually less efficient to SKIP through a unkeyed table than it is through a keyed table.

A keyed table, on the other hand, can be lightning fast as long as the data you seek is part of the key. Otherwise, just as in an unkeyed table, you are forced to do a sequential search through the table’s data fields.

Paradox tables support two types of keys or indexes.

. Primary

. Secondary

Primary Indexes

Primary indexes are directly tied to keyed tables because a primary index indicates the table is keyed. Simply, it is impossible to have a keyed table without a primary index. If you remove the primary index from a keyed table it becomes an unkeyed table.

When you identify one or more of the table’s fields as a key field (by placing an asterisk (*) at the end of the field name) during table creation/restructuring, these fields are used to create a primary index. (Note that all key fields must be together as the first fields in a table). This invisibly rebuilds the table’s structure, though in operation it only seems to change or create the key index.

Once you identify this primary key, the table is automatically maintained in the key field order and all new records are checked to make sure that no duplicate keys are added to the table. This type of index is called a unique key index. You may have only one primary key per table, but this key can be a composite of many fields in the table. You may only modify by restructuring the table.

If it is necessary to change a primary key and restructure a table, all data in the table will still be bound to the unique key restriction. This is important if you change the primary key by adding a new field to it and there is already data in the table where this new composite key would have duplicates.

DBPX handles this situation by generating a runtime error and removing every record that violates this unique key and moving it to another table named KEYVIOL.db which has the identical structure of the offending table.

The KEYVIOL.db is automatically generated whenever this situation occurs. If there is already a KEYVIOL table, it is overwritten. Because of this you should always check for the existence of a KEYVIOL.db table immediately after any type of table restructuring.

Secondary Indexes

Secondary indexes are more like common Xbase-type indexes because they can be generated or modified on the fly without having any effect on the data or table structure and aren’t restricted to unique key data.

Unlike Xbase indexes, secondary indexes can only contain a single field as their key. As mentioned earlier, primary indexes are automatically maintained so that they are always up to date. Secondary indexes are created in two different types.

. Incremental (for keyed tables)

. Independent (for unkeyed tables)

Independent indexes are created only for unkeyed tables and are not dynamically maintained in any way. Because of this they can only be considered accurate at the time of their creation. If data changes inside the table that affects the index, the index must be completely regenerated before it can be considered useful again.

Alternately, incremental indexes are created only for keyed tables and are automatically maintained similarly to primary indexes except that instead of a complete rebuild at every change, only the portion of the index affected is updated. Incremental indexes are preferable when you are handling large tables since they take considerably less time and energy to keep accurate.

Temporary Indexes

ALL, NEXT, RECORD, and REST are all supported in the scoping expressions. The syntax of these keywords is identical to that used in Clipper. Note that you can only use one scope keyword at a time. If more than one of these keywords is encountered in a scoping expression, then the last keyword in the expression is the option used.

The ALL keyword (default) specifies that all records in the table should be included in the operation, starting at the first record.

NEXT processes the specified number of records, starting with the current record. For example, NEXT 5 would process the current record and the four records following it.

The RECORD keyword identifies a specific record to process. The desired record number should follow the keyword RECORD. To process record number 3, you would include “RECORD 3” in the expression.

The REST keyword causes processing to begin with the current record, instead of starting at the beginning of the table.

Sorting

In the event that you want to reorder a table based on field data but don’t need or want to have an index attached to it, you have the option of sorting the table based on the current index. This entails a simple copy from a keyed table to an unkeyed table using the table sort function.

Passwords and Security

Although the Paradox DBMS cannot be considered a data dictionary system, it does have some special characteristics that make it more suitable to networks than the standard Xbase tables. One of these features is the level of security available.

There are two methods to make sure that your data is secure: master passwords and auxiliary passwords. As the owner of a table, you can limit access by attaching a master password to it. Auxiliary passwords can also be identified to establish access to the table and its family.

Once any type of password is identified for a table, its is encrypted. This protects it not only from unauthorized Paradox users but also from anyone trying to dissect it at the DOS file level. The encryption method used by Paradox is literally unbreakable and if you (or your users) forget a table password, there is no way to recover that information.

Auxiliary passwords allow access control at the table and field levels. Access to tables can be restricted to:

. ReadOnly: No changes to the table can be made

. Update: Changes to nonkey fields are allowed, no records can be added or deleted

. Entry: Same as update except that new records can be added

. InsertDelete: Same as Entry except that records can be inserted and deleted

. All: Full access including restructuring and table deletion

Access to the fields can be identified as:

. None: This field data cannot be displayed to the user

. ReadOnly: User can see the field value, but cannot change it

. All: Full access

With DBPX, you may perform basic database operations on Paradox tables without code changes.

Note that because Paradox tables can have primary indexes which are actually part of the table structure specification, when you open a Paradox table, its associated primary index (if applicable) is also opened and activated. The only exception to this rule is if you indicate that you want a secondary index to be activated at the time you open the table. If no primary index is available and no secondary index is specified, the table is opened in natural sequence order.

You can have up to twenty-four Paradox tables open simultaneously. These may be separate tables or the same table repeatedly or any variation in between. This might be important if you want to have more than one secondary index active for a single table, allowing you to move from one work area to another with the only change being the index order of the data in the table. Be careful with this type of multiviewed approach, however, since you will be eating up memory for each work area, despite the fact that they refer to the same table.

Sharing Data in Networks

The DBPX driver supports the native Clipper single-lock locking scheme. Therefore, in a shared environment, your application and Paradox will not see each other’s record locks. This may result in some concurrency corruption and errors.

In a shared environment, DBPX performs no record buffering; immediately writing all changes to disk.

Concurrency is an issue whenever your application is running either on a network or in some other shared environment. One example of a non- network shared environment is when your application is called from another program (like Paradox, Quatro Pro, etc.) that also has access to the Paradox tables. Even if you don’t have any plans to use your program on a network, you should design it to be smart enough not to become a problem if faced with this type of shared example.

Also be aware that many networks have different rights and privilege restrictions and you should know what they are and how to handle them.

Using (.px) and (.ntx) Files Concurrently

You can use both (.px), as well as (.x), (.y) and (.ntx) files concurrently in a Clipper program like this:

REQUEST DBPX
// (.ntx) file using default DBFNTX driver
USE File1 INDEX File1 NEW
// (.idx) files using DBPX driver
USE File2 VIA "DBPX" INDEX File2 NEW

Note, however, that you cannot use (.px) and (.ntx) files in the same work area. For example, the following does not work:

USE File1 VIA "DBFNTX" INDEX File1.ntx, File2.px

Summary

In this chapter, you were given an overview of the features and benefits of the DBPX RDD. You also learned how to link this driver and how to use it in your applications.

C5DG-5 DBFMDX Driver

Clipper 5.x – Drivers Guide

Chapter 5

DBFMDX Driver Installation and Usage

DBFMDX is the dBASE IV compatible RDD for Clipper. This driver provides (.dbf), (.dbt), and (.mdx) file format compatibility.

In This Chapter

This chapter explains how to install DBFMDX and how to use it in your applications. The following major topics are discussed:

. Overview of the DBFMDX RDD

. Installing DBFMDX Driver Files

. Linking the DBFMDX Driver

. Using the DBFMDX Driver

Overview of the DBFMDX RDD

The DBFMDX database driver provides dBASE IV compatibility, including access to (.dbf), (.mdx), and (.dbt) file formats. The driver also supports dBASE IV compatible file and record locking schemes, allowing shared access between Clipper and dBASE IV programs.

Installing DBFMDX Driver Files

The DBFMDX database driver is supplied as the file, DBFMDX.LIB.

The Clipper installation program installs this driver in the \CLIPPER5\LIB subdirectory on the drive that you specify, so you need not install the driver manually.

Linking the DBFMDX Database Driver

To link the DBFMDX database driver into an application program, you must specify DBFMDX.LIB to the linker in addition to your application object files (.OBJ).

1. To link with .RTLink using positional syntax:

     C>RTLINK <appObjectList> ,,,DBFMDX

2. To link with .RTLink using freeformat syntax:

         C>RTLINK FI <appObjectList> LIB DBFMDX

Note: These link commands all assume the LIB, OBJ, and PLL environment variables are set to the standard locations. They also assume that the Clipper programs were compiled without the /R option.

Using the DBFMDX Database Driver

To use (.mdx) files in a Clipper program:

1. Place REQUEST DBFMDX at the beginning of your application or at top of the first program file (.prg) that opens a database file using the DBFMDX driver.

2. Specify the VIA “DBFMDX” clause if you open the database file with the USE command.

-OR-

3. Specify “DBFMDX” for the <cDriver> argument if you open the database file with the DBUSEAREA() function.

-OR-

4. Use RDDSETDEFAULT(“DBFMDX”) to set the default driver to DBFMDX.

Except in the case of REQUEST, the RDD name must be a literal character string or a variable. In all cases it is important that the driver name be spelled correctly using uppercase letters.

Though the DBFMDX driver supports numbered indexes, you should avoid using them (e.g., in operations like SET ORDER and INDEXKEY()). In a multiple-index system you do not have the absolute control of the numeric position of an open index that you have in a single-index system. As you add, delete, and rebuild index TAGs, their numeric position may change. You should make all command references by name. For example:

SET ORDER TO [<nOrder> | [TAG <cOrderName>] [IN <xcOrderBagName>]]

Summary

In this chapter, you were given an overview of the features and benefits of the DBFMDX RDD. You also learned how to link this driver and how to use it in your applications.

C5DG-4 DBFCDX Driver

Clipper 5.x – Drivers Guide

Chapter 4

DBFCDX Driver Installation and Usage

DBFCDX is the FoxPro 2 compatible RDD for Clipper. As such, it connects to the low-level database management subsystem in the Clipper architecture. When you use the DBFCDX RDD, you add a number of new features including:

. FoxPro 2 file format compatibility

. Compact indexes

. Compound indexes

. Conditional indexes

. Memo files smaller than DBFNTX format

In This Chapter

This chapter explains how to install DBFCDX and how to use it in your applications. The following major topics are discussed:

. Overview of the DBFCDX RDD

. Installing DBFCDX Driver Files

. Linking the DBFCDX Driver

. Using the DBFCDX Driver

Overview of the DBFCDX RDD

The DBFCDX driver lets you create and maintain (.cdx) and (.idx) files with features different from those supplied with the original DBFNTX driver and is compatible with files created under FoxPro 2. The new features are supplied in the form of several syntactical additions to the INDEX and REINDEX commands. Specifically, you can:

. Create indexes smaller than those created with the DBFNTX
driver. The key data is stored in a compressed format that
substantially reduces the size of the index file.

. Create a compound index file that contains multiple indexes
(TAGs), making it possible to open several indexes under one file
handle. A single (.cdx) file may contain up to 99 index keys.

. Create conditional indexes (FOR / WHILE / REST / NEXT).

. Create files with FoxPro 2 file format compatibility.

Compact Indexes

Like FoxPro 2, The DBFCDX driver creates compact indexes. This means that the key data is stored in a compressed format, resulting in a substantial size reduction in the index file. Compact indexes store only the actual data for the index keys. Trailing blanks and duplicate bytes between keys are stored in one or two bytes. This allows considerable space savings in indexes with much empty space and similar keys. Since the amount of compression is dependent on many variables, including the number of unique keys in an index, the exact amount of compression is impossible to predetermine.

Compound Indexes

A compound index is an index file that contains multiple indexes (called tags). Compound indexes (.cdx)’s make several indexes available to your application while only using one file handle. Therefore, you can overcome the Clipper index file limit of 15. A compound index can have as many as 99 tags, but the practical limit is around 50. Once you open a compound index, all the tags in the file are automatically updated as the records are changed.

Once you open a compound index, all the tags contained in the file are automatically updated as the records are changed. A tag in a compound index is essentially identical to an individual index (.idx) and supports all the same features. The first tag (in order of creation) in the compound index is, by default, the controlling index.

Conditional Indexes

The DBFCDX driver can create indexes with a built-in FOR clause. These are conditional indexes in which the condition can be any expression, including a user-defined function. As the database is updated, only records that match the index condition are added to the index, and records that satisfied the condition before, but don’t any longer, are automatically removed.

Expanded control over conditional indexing is supported with the revised INDEX and REINDEX command options as in the new DBFNTX driver.

Installing DBFCDX Driver Files

The DBFCDX driver is supplied as the file, DBFCDX.LIB.

The Clipper installation program installs this driver in the \CLIPPER5\LIB subdirectory on the drive that you specify, so you need not install the driver manually.

Linking the DBFCDX Database Driver

To link the DBFCDX database driver into an application program, you must specify DBFCDX.LIB to the linker in addition to your application object files (.OBJ).

1. To link with .RTLink using positional syntax:

C>RTLINK <appObjectList> ,,,DBFCDX

2. To link with .RTLink using freeformat syntax:

C>RTLINK FI <appObjectList> LIB DBFCDX

Note: These link commands all assume the LIB, OBJ, and PLL environment variables are set to the standard locations. They also assume that the Clipper programs were compiled without the /R option.

Using the DBFCDX Database Driver

To use FoxPro 2 files in a Clipper program:

1. Place REQUEST DBFCDX at the beginning of your application or at the top of the first program file       (.prg) that opens a database file using the DBFCDX driver.

2. Specify the VIA “DBFCDX” clause if you open the database file with the USE command.

    -OR-

3. Specify “DBFCDX” for the <cDriver> argument if you open the database file with the DBUSEAREA()       function.

   -OR-

4. Use ( “DBFCDX” ) to set the default driver to DBFCDX.

    Except in the case of REQUEST, the RDD name must be a literal character string or a variable. In all       cases it is important that the driver name be spelled correctly.

The following program fragments illustrate:

  REQUEST DBFCDX
  .
  .
  .
  USE Customers INDEX Name, Address NEW VIA "DBFCDX"

     -OR-

  REQUEST DBFCDX
  RDDSETDEFAULT( "DBFCDX" ) .
  . 
  .
  USE Customers INDEX Name, Address NEW

Using (.idx) and (.ntx) Files Concurrently

You can use both (.idx) and (.ntx) files concurrently in a Clipper program like this:

// (.ntx) file using default DBFNTX driver
 USE File1 INDEX File1 NEW
// (.idx) files using DBFCDX driver
 USE File2 VIA "DBFCDX" INDEX File2 NEW

Note, however, that you cannot use (.idx) and (.ntx) files in the same work area. For example, the following does not work:

USE File1 VIA "DBFNTX" INDEX File1.ntx, File2.idx

Using (.cdx) and (.idx) Files Concurrently

You may use (.cdx) with (.idx) files concurrently (even in the same work area); however, in most cases it is easier to use a single (.cdx) index for each database file or separate (.idx) files. When using both types of index at the same time, attempting to select an Order based on its Order Number can be confusing and will become difficult to maintain.

File Maintenance under DBFCDX

When an existing tag in a compound index (.cdx) is rebuilt using INDEX ON…TAG… the space used by the original tag is not automatically reclaimed. Instead, the new tag is added to the end of the file, increasing file size.

You can use the REINDEX command to “pack” the index file. REINDEX rebuilds each tag, eliminating any unused space in the file.

If you rebuild your indexes on a regular basis, you should either delete your (.cdx) files before rebuilding the tags or use the REINDEX command to rebuild them instead.

DBFCDX and Memo Files

The DBFCDX driver uses FoxPro compatible memo (.fpt) files to store data for memo fields. These memo files have a default block size of 64 bytes rather than the 512 byte default for (.dbt) files.

DBFCDX memo files can store any type of data. While (.dbt) files use an end of file marker (ASCII 26) at the end of a memo entry, (.fpt) files store the length of the entry. This not only eliminates the problems normally encountered with storing binary data in a memo field but also speeds up memo field access since the data need not be scanned to determine the length.

Tips For Using DBFCDX

1. Make sure index extensions aren’t hard-coded in your application. The default extension for DBFCDX indexes is (.idx), not (.ntx). You can still use (.ntx) as the extension as long as you specify the extension when you create your indexes. The best way to determine index extensions in an application is to call ORDBAGEXT().

For example, if you currently use the following code to determine the existence of an index file:

IF .NOT. FILE("index.ntx")
    INDEX ON field TO index
ENDIF

Change the code to include the INDEXEXT() function, as follows:

IF .NOT. FILE("index"+ORDBAGEXT())
   INDEX ON field TO index
ENDIF

2. If your application uses memo fields, you should convert your (.dbt) files to (.fpt) files.

There are some good reasons for using (.fpt) files. Most important is the smaller block size (64 bytes). Clipper’s (.dbt) files use a fixed block size of 512 bytes which means that every time you store even 1 byte in a memo field Clipper uses 512 bytes to store it. If the data in a memo field grows to 513 bytes, then two blocks are required.

When creating (.fpt) files, the block size is set at 64 bytes to optimize it for your needs. A simple conversion from (.dbt) files to (.fpt) files will generally shrink your memo files by approximately 30%.

3. Add DBFCDX.LIB as a library to your link command or link script.

Summary

In this chapter, you were given an overview of the features and benefits of the DBFCDX RDD. You also learned how to link this driver and how to use it in your applications.

Design of Clipper

build the truly reusable routine

Clipper characteristics

Clipper, characteristics and versions

Clipper is procedural and imperative Programming language created in 1985 by Nantucket Corporation and sold later to Computer Associates, the one commercialized that it like CA-Clipper. At first Clipper was created as Compiler for the managing system interpreter of data bases dBase III (in fact seasonal versions of Nantucket included a label indicated that it thus), but with time the product evolved and matured, becoming a compiled language more powerful than the original one, not only by its own implementations but also by the extensions developed by third parties in C, Assembly and Pascal, of which it was inheriting characteristic. This turned into the tool leader of development of applications of relational databases under operating system MSDOS, mainly programs of management, accounting and invoicing ( SAGE – SP, leader of the Spanish market, uses for Contaplus and FacturaPlus ), commercial agendas and programs of pricing (approximately 80% of the insurance agencies of Spain used it in the programs of their agents).

Characteristics

Unlike other x-Base languages, Clipper never counted on a way Interpreter, similar to the one of dBase . Its utilities for handling of Base of data, such as the one of creation of tables (DBF), they gave with the source code written in Clipper and including, the user could adapt them to his needs if he wanted. They also contributed to many routines written in C and Assembly to which the user could go, to extend and even to create libraries of pre-connects complete.

Clipper works in way pure Compiler generating an object code binary; the package also provided a connector (RTLINK or DLINK) that with the object module and the libraries of pre-connects generated ejecuble a module direct. This last one granted to the Clipper applications a speed to him that other managers of data bases did not own, and, like disadvantage, the necessity to recompilar and to connect again whenever some error in the source code was corrected ( Purification was slow).

It owns characteristics that were very attractive for their time and its surroundings of work (TWO), such as: own handling of Virtual memory ( ram in disc); handling of extended memory, the applications could overcome the barrier of 640Kb of ram imposed by MSDOS ; routines and libraries can be only loaded when they are necessary and they unload of ram when no longer they make lack (it connects and overlays dynamic); the amount of registries by tables only was limited the capacity of the disc; great robustness in the applications, particularly in the designed ones for client-servant (network LAN), etc.

Although it did not own practically calculation functions such as the trigonometrical ones, that other languages like FoxPro if they incorporated; the user them could easily elaborate in C and use them like any other function of own bookstore of the package, advantage that happened of which the Clipper compiler and many of their libraries were almost completely developed in C .

Its form, administration, storage and interchange of screens were simple, effective and quick; what good dynamism to the applications developed with Clipper granted.

The language in if he were powerful, counting with a great amount of sentences, functions, memory management and variables that allowed to the programmer very flexible and efficient developments; in reasonably fast form. Also the package included complete “manual in line navegable”, that ram was loaded in memory, to requirement of the programmer, and it was acceded by the single pressure of a pair of keys.

At his long time sea bream, it has been, probably, the language relational database manager of ” low and medium porte” more used in the world. Today many Clipper developers even exist (some grouped communities and with forums in Internet), that make applications, style Windows, even using their own graphical libraries written in C and Assembly .

The first versions

The first versions denominate seasonal versions to make reference to a station of the year in their official names. All of them name like dBASE compilers . These were:

  • Nantucket Clipper Winter’84 – sent 25 of May of 1985
  • Nantucket Clipper Summer’85 – sent in 1985
  • Nantucket Clipper Winter’85 – sent 29 of January of 1986
  • Nantucket Clipper Fall’86 – sent 31 of October of 1986
  • Nantucket Clipper Summer’87 – sent 21 of December of 1987
  • Gatsoft Clipper Summer’88 – sent 16 of March of 1988

Clipper 5

Clipper 5.0 supposes a qualitative jump of the language, although it begins bad. Given the increasing popularity (Summer 87 has been used until the year 2000 like development tool), it is decided to concentrate more in extending the language that in being improved compiler of dBase. They are implemented therefore pseudo-objects and other improvements… but the product sends with numerous bugs that make that the objective public dissuades itself and continues using the Summer87 version, much more stable. The 5,01 correct many of the problems, but it will not be until the 5,2 that take place upsets massive of the developers.

Versions 5 of Nantucket are:

  • Nantucket Clipper 5,00 – sent in 1990
  • Nantucket Clipper 5,01 – sent 15 of April of 1991
  • Nantucket Clipper 5,01 Rev.129 – sent 31 of March of 1992

The American multinational Computer Associates acquires Nantucket and it is sent to improve the product strengthening the inherited characteristics of C, in particular the data type code-block (literally code block, a hybrid between macros of dBase, the evaluation of chains of characters and the leaders of functions). Another one of the improvements coming from version 5.0 is the system “Replaceable Drivers” Database; (RDD or basic drivers replacable of data), that allows with a single sentence to change between different basic norms from data. The appearance of version 5.2, with a frenetic race of subversions (with improvements and correction of errors) until 5.2c, that marks the beginning of the massive migration of those who still remained in Summer’87. The version of used Clipper of history happens more therefore. Contrary, her successor, 5,3, in spite of implementing improvements, falls in a bulk error, when not considering the compatibility with at least the most popular libraries of Clipper (as much commercial as freeware), and to consume excessive resources of TWO.

  • CA Clipper 5.01a –
  • CA Clipper 5,20 – sent 15 of February of 1993
  • CA-Clipper 5.2a – sent 15 of March of 1993
  • CA Clipper 5.2b – sent 25 of June of 1993
  • CA-Clipper 5.2c – sent 6 of August of 1993
  • CA Clipper 5.2d – sent 25 of March of 1994
  • CA-Clipper 5.2e – sent 7 of February of 1995
  • CA Clipper 5,30 – sent 26 of June of 1995
  • CA Clipper 5.3a – sent 20 of May of 1996
  • CA Clipper 5.3b – sent 20 of May of 1997

Computer Associates decides to leave Clipper before the might of Microsoft Windows, and overturns part of the development of Clipper ( project Reels of Nantucket) to its new tool CA-Line of vision Objects, that appears at the same time as 5.3 almost Clipper but the abandonment of the syntax x-Base and not to provide a tool with adapted migration, together with the high price of the product (that in addition debia to compete with other products of the own house, one of them based on BASIC ), causes that the thickness of Clipper programmers chooses to remain in versions 5.3 with libraries of third parties like FiveWin, or migrate to tools x-Base like Visual FoxPro as market TWO is reduced.

22 of April of 2002 Computer Associates and GrafX Software announces that they have reached an agreement of licensing, marketing and development of two of its languages of development: CA-Clipper and CA-Line of vision Objects.

One of the main characteristics that helped the success of Clipper was the possibility of expanding the language with routines in C and ensablador. Several of them, as CodeBase or Apollo is RDDs. With the appearance of Windows several of them were developed to carry the Clipper applications to Windows. Most popular she is the FiveWin Spanish, employee in products leaders of accounting in Spain.

In addition, the use of linkers alternative allowed to improve the generated yield of the feasible one. The most acclaimed it was Blinker, that adds a extensor of with TWO protected mode (it is used with numerous languages and compilers). It added support to compile programs and libraries for Windows.

At present the Clipper language is actively being implemented and being extended by several projects and salesmen. Between the projects of free Software we can emphasize Paper clip, Harbor and XHarbour . Between the commercial compilers XBase++ and Visual FlagShip. And Other products like ” MEDIATOR” that they offer the possibility him of connecting itself to relational Database servers like MS-SQL, MySQL and Oracle.

XBase++ has been called the Clipper Compiler of 32 bits, being at the moment the leader in innovations and incorporations to the language. Or they have been sold more than 25,000 copies of the compiler and they use from solitary developers to great companies like Hewlett-Packard or the Government of Canada.

Several of those implementations are portable thanks to their development in C ( TWO, Windows, Linux (32 and 64 bits), Unix (32 and 64 bits), and Mac OS X ), supporting several extensions of the language; they count on several extensions of the language, and several Replaceable Drivers Database (RDD) that the most popular formats of tables support, like DBF, DBTNTX, DBFCDX ( FoxPro and Comix), MachSix (Apollo), SQL, and more. All these new implementations maintain the complete compatibility with the standard x-Base sintax , at the same time as and syntax oriented to the destiny like SQLExecute()offer Object-oriented programming .

At the moment there is a free version, the Harbor Project that it has like original objective to be 100% compatible one with version 5.2 (most popular of the versions of Clipper), also are addition new characteristic like support for SQL through SQLite. Harbor is available for multiple platforms, including not only MSDOS and Windows, but also to Linux, OS/2 and others. In the month of August of the 2008 the launching of version 1.0 announced officially.

In 2005, Newsgroup of Usenet regarding Clipper comp.clipper and comp.visual-objects follow assets.

Programming in Clipper

Simple Hello world :

? ” Hello World! “

A simple mask of entrance of Base of data :

USE Customer SHARED NEW

clear screen
@  1, 0 SAY "CustNum" GET Customer->CustNum PICT "999999" VALID Customer->CustNum > 0
@  3, 0 SAY "Contact" GET Customer->Contact VALID !empty(Customer->Contact)
@  4, 0 SAY "Address" GET Customer->Address
READ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Note : This article Gathered from here.