__dbCopyStruct()

Template

Procedure

Name

__dbCopyStruct()

Category

API

Subcategory

Database

Oneliner

Create a new database based on current database structure

Syntax

      __dbCopyStruct( <cFileName>,  [<aFieldList>] )

Arguments

<cFileName> is the name of the new database file to create. (.dbf) is the default extension if none is given.

<aFieldList> is an array where each element is a field name. Names could be specified as uppercase or lowercase.

Description

__dbCopyStruct() create a new empty database file with a structure that is based on the currently open database in this work-area. If <aFieldList> is empty, the newly created file would have the same structure as the currently open database. Else, the new file would contain only fields that exactly match <aFieldList>.

__dbCopyStruct() can be use to create a sub-set of the currently open database, based on a given field list.

COPY STRUCTURE command is preprocessed into __dbCopyStruct() function during compile time.

Examples

      // Create a new file that contain the same structure
      USE TEST
      __dbCopyStruct( "mycopy.dbf" )

      // Create a new file that contain part of the original structure
      LOCAL aList
      USE TEST
      aList := { "NAME" }
      __dbCopyStruct( "onlyname.dbf",  aList )

Compliance

Clipper

Platforms

All

Files

Library is rdd

Seealso

COPY STRUCTURE, COPY STRUCTURE EXTENDED, dbCreate(), dbStruct(), __dbCopyXStruct(), __dbCreate(), __dbStructFilter()

SP_BLDDBF

BLDDBF()

  Short:
  ------
  BLDDBF() Create a DBF from a delimited string or an array

  Returns:
  --------
  <lSuccess> => Success or failure

  Syntax:
  -------
  BLDDBF(cDbfName,acDefinition)

  Description:
  ------------
  Creates DBF file named <cDbfName> from delimited
  strings in <acDefinition>.

  <acDefinition>  is either:

  1.  a Delimited string in the form
      "name,type,[size],[decimals]:name,type..."
      Fields delimited by colon, field elements delimited by commas

  2.  an array of delimited strings in
      the form "name,type,[size],[decimals]". One field
      per array element, field elements delimited by
      commas.

  Examples:
  ---------
   1. Passing long delimited string

       BLDDBF('CUSTOMER','LNAME,C,15:FNAME,;
         C,10:AGE,N,2:PROSPECT,L:')

   2. Passing array of short delimited strings

       aNewdbf       := array(4)
       aNewdbf[1]    :="LNAME,C,15"
       aNwdbf[2]     :="FNAME,C,10"
       aNewdbf[3]    :="AGE,N,2"
       aNewdbf[4]    :="PROSPECT,L"
       lSuccess      := BLDDBF('CUSTOMER',aNewdbf)

  Notes:
  -------
  BLDDBF() expects an unused area to work in, and will
  return .f. if it detects a DBF open in the current area. An
  overwrite will not be allowed. BLDDBF() uses Clipper's low level
  file functions to create the DBF file. You could also (and
  should) use Clipper 5.01's DBCREATE() function. This function is
  here mainly for compatibility with previous SuperLibs.

  Source:
  -------
  S_BLDBF.PRG

C5DG-2 RDD Architecture

Clipper 5.x – Drivers Guide

Chapter 2

Replaceable Database Driver Architecture

Clipper supports a driver architecture that allows Clipper applications to use Replaceable Database Drivers (RDDs). The RDD system makes Clipper applications data-format independent. Such applications can, therefore, access the data formats of other database systems, including the dBASE IV (.mdx), FoxPro (.cdx), and Paradox (.db) formats on a variety of equipment. This driver architecture can even support database drivers that are not file-based, although all of the drivers supplied with Clipper 5.x are file-based.

The concept of replaceable drivers is not new to this version of Clipper. In previous versions, the use of the default database driver (DBFNTX.LIB) was hidden by the fact that it was automatically linked into your application. In fact, this is still the case. The DBFNTX driver has been replaceable since it was first introduced in version 5.0. Before this version, the DBFNTX driver was the only RDD supplied as part of the system.

In This Chapter

With the introduction of the new RDDs, Clipper provides many new and enhanced commands and functions that access and manipulate databases. These language elements can enable your applications to access data regardless of the RDD under which it is ordered. There are also commands and functions that give you specific information about the RDDs in use.

The Language Implementation section of this chapter includes tables that summarize these new and enhanced language elements. This chapter also covers basic terminology, implementation principals, and general concepts of the Order Management System.

The following major topics are discussed:

. RDD Basics

. Basic Terminology

. The Language Implementation

. Order Management System

RDD Basics

The cornerstone of the replaceable database driver system is the Clipper work area. All Clipper database commands and functions operate in a work area through a database driver that actually performs the access to the stored database information. The layering of the system looks like this:

                      +———————————+

                      | Database Commands and Functions |
                      ----------------------------------|
                      |          RDD Interface          |
                      |---------------------------------|
                      |         Database driver         |
                      |---------------------------------|
                      |           Stored Data           |
                      +---------------------------------+

 In this system, each work area is associated with a single database driver. Each database driver, in turn, is supplied as a separate library file (.LIB) you link into your application programs. Within an application, you specify the name of the database driver when you open or access a database file or table with the USE command or DBUSEAREA() function. If you specify no database driver at the time a file is opened, the default driver is used. You may select which driver will be used as the default driver.

Once you open a database in a work area, the RDD used for that work area is automatically used for all operations on that database (except commands and functions that create a new table). Any command or function that creates a new table (i.e., SORT, CREATE FROM, DBCREATE(), etc.) uses the default RDD. Most of the new commands and functions let you specify a driver other than the default driver.

The normal default database driver, DBFNTX (which supports the traditional (.dbf), (.ntx), and (.dbt) files) is installed into your \CLIPPER5\LIB directory. This driver is linked into each program automatically to provide backwards compatibility.

To use any of the other supplied drivers, either as an additional driver or an alternate driver, you must use the REQUEST command to assure that the driver will be linked in. You must also include the appropriate library on the link line.

All Clipper applications will automatically include code generated by RDDSYS.PRG from the \CLIPPER5\SOURCE\SYS subdirectory. If you wish to automatically load another RDD, you must modify and compile RDDSYS.PRG and link the resulting object file into your application. The content of the default RDDSYS.PRG is shown below. Only the portion in bold should be modified

 
     //  Current RDDSYS.PRG
     #include "rddsys.ch"

     ANNOUNCE RDDSYS                     // This line must not change
     INIT PROCEDURE RddInit
        REQUEST DBFNTX                   // Force link for DBFNTX RDD
        RDDSETDEFAULT( "DBFNTX" )        // Set up DBFNTX as default
                                         // driver

        RETURN

     // eof: rddsys.prg

To change the default to a new automatically-loading driver, modify the bold lines in RDDSYS.PRG to include the name of the new driver. For example:

     //  Revised RDDSYS.PRG
     #include "rddsys.ch"

     ANNOUNCE RDDSYS                     // This line must not change
     INIT PROCEDURE RddInit
        REQUEST DBFCDX                   // Force link for DBFCDX RDD
        RDDSETDEFAULT( "DBFCDX" )        // Set up DBFCDX as default
                                         // driver

        RETURN

     // eof: rddsys.prg

If you change this file, all Clipper applications in which it is linked will automatically include the new RDD.

To use any RDD other than the default, you must explicitly identify it through use of the VIA clause of the USE command.

You need not disable the automatic DBFNTX loading to use other RDDs in your applications, but if your application will not use any DBFNTX functionality, you can save its code overhead by disabling it.

To completely disable the automatic loading of a default RDD, remove the two lines shown above in bold. For example:

     //  New Revised RDDSYS.PRG
     //  disables auto-loading
     #include "rddsys.ch"

     ANNOUNCE RDDSYS                     // This line must not change
     INIT PROCEDURE RddInit

        RETURN
     // eof: rddsys.prg

Basic Terminology

The RDD architecture introduces several new terms and concepts that are key to the design and usage of RDDs. You should familiarize yourself with these concepts and terms as you begin to use the RDD functionality. The meaning of some earlier terminology is also further defined. The following RDD functional glossary defines the terminology for all RDDs.

. Key Expression : A valid Clipper expression that creates a key value from a single record.

. Key Value : A value that is based on value(s) contained within database fields, associated with a particular record in a database.

. Identity : A unique value guaranteed by the structure of the data file to reference a specific record in a database even if the record is empty. In the Xbase file (.dbf), the identity is the record number; but it could be the value of a unique primary key or even the offset of an array in memory.

. Keyed-Pair : A pair consisting of a key value and an identity.

. Identity Order : Describes a database arranged by identity. In Xbase, this refers to the physical arrangement of the records in the database in the order in which they were entered (natural order).

. Tag : A set of keyed-pairs that provides ordered access to the table based on a key value. Usually, an Order in a multiple-Order index (Order). An Order.

. Order : A named mechanism (index) that provides logical access to a database according to the keyed-pairs. This term encompasses both single indexes and the Tags in multiple-Tag indexes.

Orders are not, themselves, data files. They provide access to data that gives the appearance of an ordering of the data in a specific way. This ordering is defined by the relationships between keyed- pairs. An Order does not change the physical (the natural or entry) order of data in a database.

. Controlling Order : The active Order (index) for a particular work area. Only one Order may control a work area at any time, and it controls the order in which the database is accessed during paging and searching.

. Order List : A list of all the Orders available to the database in the specified work area.

. Order Bag : A container that holds zero or more Orders. Normally a disk or memory file. A traditional index like (.ntx) is an Order Bag that holds only one Order. A multiple-Tag index (.mdx or .cdx) is an Order Bag that holds zero or more Orders. Though Order Bags may be a memory or disk file, Clipper 5.x only supports Order Bags as disk files.

. Record : A record in the traditional database paradigm is a row of one or more related columns (fields) of data. In the expanded architecture of Clipper, a record could be data that does not exactly fit this definition.

A record is, in this expanded context, data associated with a single identity. In an Xbase data structure, this corresponds to a row (fields associated with a record number); in other data structures, this may not be the case.

In this document we use “record” in the traditional sense, but you should be aware that Clipper permits expansion of the meaning of record.

. single-Order Bag : An Order Bag that can contain only one Order. The (.ntx) and (.ndx) files are examples of single-Order Bags.

. multiple-Order Bag : An Order Bag that can contain any number of Orders; a multiple-Tag index. The (.cdx) and (.mdx) files are examples of multiple-Order Bags.

. maintainable scoped Orders : Scoped (filtered) Orders created using the FOR clause. The FOR condition is stored in the index header. Orders of this type are correctly updated using the expression to reflect record updates, deletions and additions.

. non-maintainable/temporary Orders : Orders created using the WHILE or NEXT clauses. These Orders are useful because they can be created quickly. However, the conditions in these clauses are not stored in the index header. Therefore, Orders of this type are not correctly updated to reflect record updates, deletions and additions. They are only for temporary use.

. Lock List : A list of the records that are currently locked in the work area.

The Language Implementation

To support the RDD architecture and let you design applications that are independent of the data format you are using, many existing Clipper commands and functions have been enhanced, and several new language elements have been added. The following tables summarize these changes and additions. See the Reference chapter of this guide for more detailed information on a particular item.

     Enhanced Commands and Functions
     ------------------------------------------------------------------------
     Command/Function  Changes
     ------------------------------------------------------------------------
     APPEND FROM       VIA clause
     COPY TO           VIA clause
     DBAPPEND()        Terminology
     GO                Terminology
     DBAPPEND()        Terminology
     INDEX             ALL, EVAL, EVERY, NEXT, RECORD, REST, TAG, and
                       UNIQUE clauses
     SEEK              SOFTSEEK option
     SET INDEX         ADDITIVE clause
     SET ORDER         IN, TAG clauses
     DBSETINDEX()      Terminology
     RECNO()           Terminology
     ------------------------------------------------------------------------

     New Commands and Functions
     ------------------------------------------------------------------------
     Command/Function    Description
     ------------------------------------------------------------------------
     DELETE TAG          Delete a Tag (Order)
     DBGOTO()            Position record pointer to a specific identity
     DBRLOCK()           Lock the record at the current or specified identity
     DBRLOCKLIST()       Return an array of the currently locked records
     DBRUNLOCK           Release all or specified record locks
     ORDBAGEXT()         Return the Order Bag file extension
     ORDBAGNAME()        Return the Order Bag name of a specific Order
     ORDCREATE()         Create an Order in an Order Bag
     ORDDESTROY()        Remove a specified Order from an Order Bag
     ORDFOR()            Return the FOR expression of an Order
     ORDKEY()            Return the Key expression of an Order
     ORDLISTADD()        Add Order Bag contents or single Order to the Order
                         List
     ORDLISTCLEAR()      Clear the current Order List
     ORDLISTREBUILD()    Rebuild all Orders in the Order List of the current
                         work area
     ORDNAME()           Return the name of an Order in the work area
     ORDNUMBER()         Return the position of an Order in the current Order
                         List
     ORDSETFOCUS()       Set focus to an Order in an Order List
     RDDLIST()           Return an array of the available Replaceable
                         Database Drivers
     RDDNAME()           Return the name of the RDD active in the current or
                         specified work area
     RDDSETDEFAULT()     Set or return the default RDD for the application
     ------------------------------------------------------------------------

User Interface Levels

We want to make it easy for you to quickly take advantage of the added functionality provided in Clipper 5.x. In order to effectively use the RDDs, you should read the following discussions. They are provided as a means of identifying the degree of programming knowledge or Clipper experience that will let you effectively use the RDD features.

For this purpose the RDD feature set is arbitrarily divided into levels A and B. Tables listing the commands or functions that comprise these access levels are also supplied. In addition, an RDD Features Summary is provided in table form which outlines the features available in each driver. The commands and functions in both of these levels of access are described in the Reference chapter of this guide.

Level A – Command-Level Interface

Level A. a simple command-level interface very similar to those found in other languages (e.g., dBASE IV, FoxPro). This is the primary access for new Clipper users who may or may not be familiar with other languages.

The following table lists the commands and functions accessible by the Clipper programmer with background in languages such as dBASE or FoxPro. The commands and functions in this table provide access to the additional features without requiring an advanced knowledge of Clipper or other programming concepts.

     Basic Commands and Functions
     ------------------------------------------------------------------------
     Command/Function  Changes
     ------------------------------------------------------------------------
     DELETE TAG        Delete a Tag
     GOTO              Move the pointer to the specified identity
     INDEX             Create an index file
     SEEK              Search an Order for a specified key value
     SET INDEX         Open one or more Order Bags in the current work area
     SET ORDER         Select the controlling Order
     DBAPPEND()        Append a new record to the current Lock List
     DBRLOCK()         Lock the record at the current or specified identity
     DBRLOCKLIST()     Return an array of the current Lock List
     DBRUNLOCK         Release all or specified record locks
     ------------------------------------------------------------------------

Level B – Function-Level Interface

Level B. Clipper also adds a function level interface that not only allows access to the enhanced functionality of the drivers, but permits the building of higher-level functions using these composing behaviors. This level is meant for more experienced Clipper users who need to take advantage of the full power of the driver and Order Management System.

The following table lists the DML and Order Management functions recommended to the intermediate to advanced Clipper programmer. These functions provide the greatest flexibility in accessing the extended features of these drivers

     Advanced Functions (including Order Management)
     ------------------------------------------------------------------------
     Command/Function    Description
     ------------------------------------------------------------------------
     DBAPPEND()          Append a new record to the current Lock List
     DBRLOCK()           Lock the record at the current or specified identity
     DBRLOCKLIST()       Return an array of the current Lock List
     DBRUNLOCK()         Release all or specified record locks
     ORDBAGEXT()         Return the default Order Bag RDD extension
     ORDBAGNAME()        Return the Order Bag name of a specific Order
     ORDCREATE()         Create an Order in an Order Bag
     ORDDESTROY()        Remove a specified Order from an Order Bag
     ORDFOR()            Return the FOR expression of an Order
     ORDKEY()            Return the Key expression of an Order
     ORDLISTADD()        Add Order Bag contents or single Order to the Order
                         List
     ORDLISTCLEAR()      Clear the current Order List
     ORDLISTREBUILD()    Rebuild all Orders in the Order List of the current
                         work area
     ORDNAME()           Return the name of an Order in the work area
     ORDNUMBER()         Return the position of an Order in the current Order
                         List
     ORDSETFOCUS()       Set focus to an Order in an Order List
     RDDLIST()           Return an array of the available Replaceable
                         Database Drivers
     RDDNAME()           Return the name of the RDD active in the current or
                         specified work area
     RDDSETDEFAULT()     Set or return the default RDD for the application
     ------------------------------------------------------------------------

RDD Features

The following decision table summarizes the availability of key features across RDDs. It lists the features available in each RDD so you can use it as an aid in correct RDD implementation and data access.

     RDD Features Summary
     ------------------------------------------------------------------------
     Item                                NTX   NDX   MDX   CDX  DBPX
     ------------------------------------------------------------------------
     Implicit record unlocking in        Yes   Yes   Yes   Yes  Yes
     single lock mode
     Multiple Record Locks               Yes   Yes   Yes   Yes  No
     Number of Concurrent Record Locks   *1    *1    *1    *1   1
     Order Management (Tag support)      Yes   Yes   Yes   Yes  No
     Orders (Tags) per Order Bag (File)  1     1     47    50   N/A
     Number of Order Bags (Files)        15    15    15    15   N/A
     per work area
     Conditional Indexes (FOR clause)    Yes   No    Yes   Yes  No
     Temporary (Partial) Indexes         Yes   No    No    Yes  No
     (WHILE, ... )
     Descending via DESCENDING clause    Yes   No    Yes   Yes  No
     Unique via the UNIQUE clause        Yes   Yes   Yes   Yes  No
     EVAL and EVERY clause support       Yes   No    No    Yes  No
     Production/Structural Indexes       No    No    Yes   Yes  No
     Maximum Key Expression length       256   256   220   255  N/A
     (bytes)
     Maximum FOR Condition length        256   N/A   261   255  N/A
     (bytes)
     ------------------------------------------------------------------------

     *1 determined by available memory.

Clipper 5.x Order Management

Clipper includes a new Order Management System which provides a more effective and flexible way of indexing data. The main objective of the new Order Management implementation is to raise the Xbase indexing paradigm from a low level of abstraction (Xbase database specific) to a higher, more robust, level. This higher level of abstraction allows the user to build new commands and functions.

Low level abstraction refers to manipulation of discrete elements in the database architecture (i.e., field names and sizes, methods of handling controlling indexes, etc.).

High level abstraction refers to manipulation of general elements in a data source. It lets us, for example, set a controlling Order without explicitly addressing the character of the data file structure. This higher level of abstraction was achieved by reviewing all the processes that indexes have in common.

The Order Management function set was generically named (i.e. non-dbf specific) to provide a semantic that could encompass future RDD implementations that may not be file-bound. For example, an RDD could easily be created that orders (indexes) on a memory array, or other data structure, instead of a database. Therefore, all Order Management functions simply begin with ORD (for Order). You will find the function names to be self-explanatory (e.g., ORDCREATE() creates an Order, and ORDDESTROY() destroys an Order).

Concept

An Order is a set of keyed-pairs that provides a logical ordering of the records in an associated database file. Each key in an Order (index) is associated with a particular identity (record number) in the data set (database file). The records can be processed sequentially in key order, and any record can be located by performing a SEEK operation with the associated key value. An Order never physically changes the data that it’s applied against, but creates a different view of that data.

There are at least four basic types of processes that you can perform with an Order:

1. Ordering: Changes the sequence in which you view the data records.

2. Scoping: Constrains the visibility of data to specified upper and lower bounds. Determines the range of data items included, through a scoping rule, like the WHILE clause.

3. Filtration: Visibility of data is subject to conditional evaluation. Filtration determines which items of data are included, through a filter rule, like the FOR clause.

4. Translation: Values in underlying data source are translated (or converted) in some form based on a selection criteria. For example:

INDEX ON IIF(CUSTID > 1000, "NEW", "OLD")

The difference between scope and condition as it applies to FOR and WHILE is that the WHILE clause provides scope, but not filtering, but a FOR clause can provide both.

There are three primary elements in Order Management:

. Order: An Order is a set that has two elements in it: an Order Name, which is a logical name that can be referenced, and an Order Expression which supplies the view of the data. The Order Name provides logical access to the expression and the Order Expression provides a way of viewing the underlying data source. Data ordering can also be modified to ascending or descending sequence.

– Order Name: An Order Name is a symbolic name, that you use to manipulate an Order, like a file’s alias. The difference between an Order Name and the Order Number with which you would normally access indexes (Orders), is that the Order Name is stored in the index file. It is available each time you run the program, and is maintained by the system. The Order Number is generated each time the Order is added to an Order List and may change from one program execution to another. This makes Order Name the preferred means of referencing Orders.

– Order Expression: Is any valid Clipper expression. This is an index expression such as:

CUSTLIST->CUSTID

This expression produces the ordered view of the data. The values derived from this expression are sorted, and it is the relationship of these values to one another that provides the actual ordering.

. Order Number: An Order Number is provided by the Order List. An Order Number is only valid as long as the work area to which it belongs is open.

– Order Numbers provide one of the services performed by Order Names, allowing you to access a specific Order. In general, you should avoid accessing Orders by number.

– The ORDNUMBER() function returns the ordinal position of the specified <orderName> within the specified <orderList>.

. Order Bag: Unsorted collection of Orders. Each Order contains two elements (Order Name and Order Expression). Each Order Bag may have zero to n Orders. The maximum is determined by the RDD driver being used. Order Bags are similar to multiple-index files in that there’s no guarantee of any specific order within the container or Bag. Within an Order Bag you can access specific Orders by referencing a particular Order Name. Order Bags have persistence between activations of the program.

. Order List: An Order List orders the collection of Orders that are associated with and active in the current work area. It provides an access to the Orders active within a given work area. Each work area has an Order List, and there is only one Order List per work area. An Order List is created when a new work area is opened, and exists only as long as that work area is active. Once you close a work area, the Order List ceases to exist.

When you SET INDEX TO, the contents of the Order Bag are emptied into the Order List. At this point, the Orders in the Order List are active in the work area, where they will be updated as the data associated with the work area is modified. You may access an Order in the list by its Order Number or by its Order Name. You should access an Order by its name rather than a hard-coded ordinal position. You can make any Order in the Order List the controlling Order by giving it focus, as explained below.

. Order List Focus: Order List Focus is, essentially, a pointer to the Order that is used to change the view of the data. It is synonymous with controlling Order or controlling index, and defines the active index order. The SET ORDER TO command does not modify the Order List in any way. It does not clear the active indexes. It only changes the Order List Focus (the controlling order in the Order List).

Notes

The following list contains specific information regarding Order Bag usage and limitations with DBFNDX and DBFNTX index files:

. Single-Order Bags: With DBFNDX and DBFNTX you can explicitly assign the Order Name within the Order creation syntax. You can then use the Order Name in any command or function that accepts an Order Name (Tag) as a parameter.

. Single-Order Bag with INDEX ON: Single-Order Bags may retain the Order Name between activations. During creation, DBFNTX stores an optionally supplied Order Name in the file’s header for subsequent use. Therefore, the Order Name is not necessarily the same as that of the file. By contrast, DBFNDX cannot store an Order Name since this would prevent dBASE from accessing the file. By default DBFNDX Orders inherit the name of their index file.

Summary

This chapter has introduced you to the RDD concept, giving you specific information on the architecture that implements RDDs in Clipper. The basic terminology of RDDs has also been defined.

Finally, you have seen an overview of the language enhancements designed to make using RDDs straightforward and to let you build applications that do not depend on the RDD in use. The next chapter elaborates on these language enhancements, discussing syntax and usage in detail.

C5_DBCREATE

 DBCREATE()
 Create a database file from a database structure array
------------------------------------------------------------------------------
 Syntax

     DBCREATE(<cDatabase>, <aStruct>
        [<cDriver>]) --> NIL

 Arguments

     <cDatabase> is the name of the new database file, with an optional
     drive and directory, specified as a character string.  If specified
     without an extension, .dbf is assumed.

     <aStruct> is an array that contains the structure of <cDatabase> as
     a series of subarrays, one per field.  Each subarray contains the
     definition of each field's attributes and has the following structure:

     Field Definition Subarray
     ------------------------------------------------------------------------
     Position     Metasymbol     Dbstruct.ch
     ------------------------------------------------------------------------
     1            cName          DBS_NAME
     2            cType          DBS_TYPE
     3            nLength        DBS_LEN
     4            nDecimals      DBS_DEC
     ------------------------------------------------------------------------

     <cDriver> specifies the replaceable database driver (RDD) to use to
     process the current work area.  <cDriver> is the name of the RDD
     specified as a character expression.  If you specify <cDriver> as a
     literal value, you must enclose it in quotes.

 Returns

     DBCREATE() always returns NIL.

 Description

     DBCREATE() is a database function that creates a database file from an
     array containing the structure of the file.  You may create the array
     programmatically or by using DBSTRUCT().  DBCREATE() is similar to the
     CREATE FROM command which creates a new database file structure from a
     structure extended file.  Use CREATE or COPY STRUCTURE EXTENDED commands
     to create a structure extended file.

     Before using DBCREATE(), you must first create the <aStruct> array and
     fill it with the field definition arrays according to the structure in
     Field Definition Subarray table (above).  There are some specific rules
     for creating a field definition array, including:

     .  Specify all field attributes with a value of the proper data
        type for the attribute.  The decimals attribute must be specified--
        even for non-numeric fields.  If the field does not have a decimals
        attribute, specify zero.

     .  Specify the type attribute using the first letter of the data
        type as a minimum.  Use longer and more descriptive terms for
        readability.  For example, both "C" and "Character" can be specified
        as the type attribute for character fields.

     .  In Clipper, character fields contain up to 64,000
        characters.  Unlike the CREATE FROM command, DBCREATE() does not use
        the decimals attribute to specify the high-order part of the field
        length.  Specify the field length directly, regardless of its
        magnitude.

     To make references to the various elements of the field definition
     subarray more readable, the header file called Dbstruct.ch is supplied.
     It contains the #defines to assign a name to the array position for each
     field attribute.  It is located in \CLIP53\INCLUDE.

 Notes

     .  Duplicate field names: DBCREATE() does not check for duplicate
        field names.  Therefore, be careful not to use the same field name
        twice.

     .  EG_ARG error: DBCREATE() generates an EG_ARG error if the
        filename is NIL.

 Examples

     .  This example creates an empty array and then adds field
        definition subarrays using the AADD() function before creating
        People.dbf.  You might use this technique to add field definitions to
        your structure array dynamically:

        aDbf := {}
        AADD(aDbf, { "Name", "C", 25, 0 })
        AADD(aDbf, { "Address", "C", 1024, 0 })
        AADD(aDbf, { "Phone", "N", 13, 0 })
        //
        DBCREATE("People", aDbf)

     .  This example performs the same types of actions but declares
        the structure array as a two-dimensional array, and then uses
        subscript addressing to specify the field definitions.  It will be
        created using the DBFMDX RDD:

        #include "Dbstruct.ch"
        //
        LOCAL aDbf[1][4]
        aDbf[1][ DBS_NAME ] := "Name"
        aDbf[1][ DBS_TYPE ] := "Character"
        aDbf[1][ DBS_LEN ]  := 25
        aDbf[1][ DBS_DEC ]  := 0
        //
        DBCREATE("Name", aDbf, "DBFMDX")

 Files   Library is CLIPPER.LIB, header file is Dbstruct.ch.

See Also: AFIELDS()* COPY STRU EXTE CREATE FROM DBSTRUCT()



Hash vs Table

Consider a table for customers records with two character fields : Customer ID and customer name:

Cust_ID Cust_Name
CC001 Pierce Firth
CC002 Stellan Taylor
CC003 Chris Cherry
CC004 Amanda Baranski

 It’s known all possible and necessary operations on a table: APPEND, DELETE, SEEK and so on; by the way, for SEEK we need an index file also.

Listing this table is quite simple:

USE CUSTOMER
WHILE .NOT. EOF()
   ? CUST_ID, CUST_NAME
   DBSKIP()
ENDDO

 If our table is sufficiently small, we can find a customer record without index and SEEK :

LOCATE FOR CUST_ID = “CC003”
? CUST_ID, CUST_NAME

If we want all our data will stand in memory and we could manage it more simple and quick way, we would use an array ( with some considerations about size of table; if it is too big, this method will be problematic ) :

aCustomer := {}    // Declare / define an empty array
USE CUSTOMER
WHILE .NOT. EOF()
   AADD(aCustomer, { CUST_ID, CUST_NAME } )
   DBSKIP()
ENDDO
Traversing this array is quite simple :

FOR nRecord := 1 TO LEN( aCustomer )

    ? aCustomer[ nRecord, 1 ], aCustomer[ nRecord, 2 ]
NEXT
or :

a1Record := {}

FOR EACH a1Record IN aCustomer
   ? a1Record[ 1 ], a1Record[ 2 ]
NEXT

And locating a specific record too:

nRecord := ASCAN( aCustomer, { | a1Record | a1Record[ 1 ] == “CC003” } )

? aCustomer[ nRecord, 1 ], aCustomer[ nRecord, 2 ]

A lot of array functions are ready to use for maintain this array : ADEL(), AADD(), AINS() etc …

Now, let’s see how we could use a hash for achieve this job :

hCustomer := { => } // Declare / define an empty hash

USE CUSTOMER
WHILE .NOT. EOF()
   hCustomer[ CUST_ID ] := CUST_NAME
   DBSKIP()
ENDDO
Let’s traversing :

h1Record := NIL

FOR EACH h1Record IN hCustomer
   ? h1Record: __ENUMKEY(),h1Record:__ENUMVALUE()
NEXT

Now, we have a bit complicate our job; a few field addition to the table :

No: Field Name Type Width  Dec Decription

1

 CUST_ID

C

 5

0

Id ( Code )

2

 CUST_NAME

C

10

0

Name

3

 CUST_SNAM

C

10

0

Surname

4

 CUST_FDAT

D

 8

0

First date

5

 CUST_ACTV

L

 1

0

Is active ?

6

 CUST_BLNCE

N

11

2

Balance

 While <key> part of an element of a hash may be C / D / N / L type; <xValue> part of hash too may be ANY type of data, exactly same as arrays.

So, we can make fields values other than first ( ID) elements of an array:

hCustomer := { => } // Declare / define an empty hash
USE CUSTOMER
WHILE .NOT. EOF()
   a1Data:= { CUST_NAME, CUST_SNAM, CUST_FDAT, CUST_ACTV, CUST_BLNCE }
   hCustomer[ CUST_ID ] := a1Data
   DBSKIP()
ENDDO
Let’s traversing :

h1Record := NIL

FOR EACH h1Record IN hCustomer
   a1Key  := h1Record:__ENUMKEY()
   a1Data := h1Record:__ENUMVALUE()
   ? a1Key
   AEVAL( a1Data, { | x1 | QQOUT( x1 ) } )
NEXT
*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
/*
Hash vs Tables
 
*/
#define NTrim( n ) LTRIM( STR( n ) )
#define cLMarj SPACE( 3 )
PROCEDURE Main()

  SET DATE GERM
  SET CENT ON
  SET COLO TO "W/B"
  SetMode( 40, 120 )
 
  CLS
 
  hCustomers := { => } // Declare / define an empty PRIVATE hash
 
  IF MakUseTable() 
 
     Table2Hash()
 
     * Here the hash hCustomers may be altered in any way
 
     ZAP
 
     Hash2Table()
 
  ELSE
      ? "Couldn't make / USE table"
  ENDIF
 
  ?
  @ MAXROW(), 0
  WAIT "EOF HashVsTable.prg"
 
RETURN // HashVsTable.Main()
*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.
PROCEDURE Table2Hash()
   hCustomers := { => } 
   WHILE .NOT. EOF()
     hCustomers[ CUST_ID ] := CUST_SNAM
     DBSKIP()
   ENDDO
 
   ListHash( hCustomers, "A hash transferred from a table (single value)" )
 
   hCustomers := { => } // Declare / define an empty hash
   DBGOTOP()
   WHILE .NOT. EOF()
      hCustomers[ CUST_ID ] := { CUST_NAME, CUST_SNAM, CUST_FDAT, CUST_ACTV, CUST_BLNCE }
      DBSKIP()
   ENDDO
 
   ListHash( hCustomers, "A hash transferred from a table (multiple values)" )
 
RETURN // Table2Hash()

*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.

PROCEDURE Hash2Table()
   LOCAL h1Record,;
         c1Key,;
         a1Record,;
         n1Field
 
   FOR EACH h1Record IN hCustomers
      c1Key := h1Record:__ENUMKEY()
      a1Record := h1Record:__ENUMVALUE()
      DBAPPEND()
      FIELDPUT( 1, c1Key )
      AEVAL( a1Record, { | x1, n1 | FIELDPUT( n1 + 1 , x1 ) } )
   NEXT h1Record
   DBGOTOP()
 
   ?
   ? "Data trasferred from hash to table :"
   ?
   WHILE ! EOF()
      ? STR( RECN(), 5), ''
      FOR n1Field := 1 TO FCOUNT()
         ?? FIELDGET( n1Field ), ''
      NEXT n1Field
      DBSKIP()
   ENDDO 
 
RETURN // Hash2Table()

*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.

PROCEDURE ListHash( hHash, cComment )
 
  LOCAL x1Pair
 
  cComment := IF( HB_ISNIL( cComment ), '', cComment )
 
  ? 
  ? cComment // , "-- Type :", VALTYPE( hHash ), "size:", LEN( hHash )
  ?
  IF HB_ISHASH( hHash ) 
     FOR EACH x1Pair IN hHash
        nIndex := x1Pair:__ENUMINDEX()
        x1Key := x1Pair:__ENUMKEY()
        x1Value := x1Pair:__ENUMVALUE()
        ? cLMarj, NTrim( nIndex ) 
*       ?? '', VALTYPE( x1Pair )
        ?? '', x1Key, "=>"
*       ?? '', VALTYPE( x1Key ) 
*       ?? VALTYPE( x1Value ) 
        IF HB_ISARRAY( x1Value ) 
           AEVAL( x1Value, { | x1 | QQOUT( '', x1 ) } )
        ELSE 
           ?? '', x1Value
        ENDIF 
     NEXT
  ELSE
    ? "Data type error; Expected hash, came", VALTYPE( hHash ) 
  ENDIF HB_ISHASH( hHash )
RETURN // ListHash()
*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.

FUNCTION MakUseTable() // Make / USE table
 
 LOCAL cTablName := "CUSTOMER.DBF"
 LOCAL lRetval, aStru, aData, a1Record 
 
 IF FILE( cTablName ) 
    USE (cTablName)
 ELSE
    aStru := { { "CUST_ID", "C", 5, 0 },;
               { "CUST_NAME", "C", 10, 0 },;
               { "CUST_SNAM", "C", 10, 0 },;
               { "CUST_FDAT", "D", 8, 0 },;
               { "CUST_ACTV", "L", 1, 0 },;
               { "CUST_BLNCE", "N", 11, 2 } }
    * 
    * 5-th parameter of DBCREATE() is alias - 
    * if not given then WA is open without alias 
    *                              ^^^^^^^^^^^^^ 
    DBCREATE( cTablName, aStru, , .F., "CUSTOMER" ) 
 
    aData := { { "CC001", "Pierce", "Firth", 0d20120131, .T., 150.00 },; 
               { "CC002", "Stellan", "Taylor", 0d20050505, .T., 0.15 },;
               { "CC003", "Chris", "Cherry", 0d19950302, .F., 0 },;
               { "CC004", "Amanda", "Baranski", 0d20011112, .T., 12345.00 } }
 
    FOR EACH a1Record IN aData
        CUSTOMER->(DBAPPEND())
        AEVAL( a1Record, { | x1, nI1 | FIELDPUT( nI1, X1 ) } )
    NEXT a1Record 
    DBGOTOP()
 
 ENDIF 
 
 lRetval := ( ALIAS() == "CUSTOMER" )
 
RETURN lRetval // MakUseTable()

*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
 
HashVsTable

Uniform Arrays

 

If a multi-dimension array

–          have a fixed number elements in each dimension and

–          each column contains the same type of information for each row in array

called “uniform”.

This structure is similar to a table structure.

Built-in functions DBSTRUCT() and DIRECTORY() produces uniform arrays.

Array produced by DBSTRUCT() will have field count  in size and the structure of an array is:

Field Name  C
Field Type  C
Field Width N
Field Dec   N

And DIRECTORY() function produces an array with elements as file count and with this structure:

File Name        C
File Size        N
File Date        D
File Time        C
File Attributes  C

Building, maintaining and using those arrays is simple as possible.

Let’s look at a sample .prg:

-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
#include "directry.ch"
#include "dbstruct.ch"
PROCEDURE Main()
  SET DATE GERM
  SET CENT ON
 
  ?
  ? "Uniform arrays :" 
  ?
 
  ?
  ? " Directory file list :"
  ?
 
  FileList()
 
  ?
  ? " Table structure list :"
  ?
  IF MakUseTable()
     DispStru() 
  ELSE
     ? "Couldn't USE or Make th table." 
  ENDIF
 
  ?
  @ MAXROW(), 0
  WAIT "EOF UF_Arrays.prg"
 
RETURN // UF_Arrays.Main
*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._

PROCEDURE FileList()
  LOCAL aFList := DIRECTORY( "C:\Harbour\*.*" )
  LOCAL a1File
 
  FOR EACH a1File IN aFList 
     ? SPACE( 4 ),;
       PAD( a1File[ F_NAME ], 13 ),; /* File name */ 
       TRAN( a1File[ F_SIZE ], "999,999,999" ),; /* File size */
       a1File[ F_DATE ],; /* File date */
       a1File[ F_TIME ],; /* File time */
       a1File[ F_ATTR ] /* File attribute */
 NEXT
 
RETURN // FileList()
 
*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
FUNCTION MakUseTable() 
 
  LOCAL cTablName := "CUSTOMER.DBF"
  LOCAL lRetval, aStru 
 
  IF FILE( cTablName ) 
     USE (cTablName)
  ELSE
     aStru := { { "CUST_ID",    "C",  5, 0 },;
                { "CUST_NAME",  "C", 10, 0 },;
                { "CUST_SNAM",  "C", 10, 0 },;
                { "CUST_FDAT",  "D",  8, 0 },;
                { "CUST_ACTV",  "L",  1, 0 },;
                { "CUST_BLNCE", "N", 11, 2 } }
    * 
    * 5-th parameter of DBCREATE() is alias - 
    * if not given then WA is open without alias 
    *                              ^^^^^^^^^^^^^ 
    DBCREATE( cTablName, aStru, , .F., "CUSTOMER" ) 
 ENDIF 
 
 lRetval := ( ALIAS() == "CUSTOMER" )
 
RETURN lRetval // MakUseTable()
*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
PROCEDURE DispStru()
   LOCAL nTotal := 1
 
   IF SELECT() > 0
      aStructur := DBSTRUCT()
      ? SPACE( 4 ), "No: Field Name Type Width Dec"
      ? SPACE( 4 ), "--- ---------- ---- ----- ---"
      AEVAL( aStructur, { | aF1, nFNo | ;
             QOUT( SPACE( 4 ),; // Left Marj 
                   PADL( nFNo, 3 ),; // Field No
                   PADR( aF1[ DBS_NAME ], 11 ),; // Field Name
                   PADC( aF1[ DBS_TYPE ], 4 ),; // Field Type
                   PADL( aF1[ DBS_LEN ], 4 ),; // Field Len
                   PADL( aF1[ DBS_DEC ], 3 )),; // Field Dec 
             nTotal += aF1[ 3 ] } )
 
      ? SPACE( 4 ), "--- ---------- ---- ----- ---"
      ? SPACE( 4 ), "** Total ** ", TRAN( nTotal, "9,999" )
   ELSE
      ? "Current work area is empty"
   ENDIF 
 
RETURN // DispStru()
*-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
 
UF_Arrays

C5 Database Functions

AFIELDS() :

Fill arrays with the structure of the current database file

AFIELDS([<aFieldNames>],
    [<aTypes>],
    [<aWidths>],
    [<aDecimals>]) --> nFields

ALIAS() : 

Return a specified work area alias

ALIAS([<nWorkArea>]) --> cAlias

BOF() : 

Determine when beginning of file is encountered

BOF() --> lBoundary

DBAPPEND() : 

Add a new record

DBAPPEND() --> NIL

DBCLEARFILTER() : 

Clear a filter condition

    DBCLEARFILTER() –> NIL

DBCLEARIND() :  Close all indexes for the current work area

    DBCLEARINDEX() --> NIL

DBCLEARREL() : 

Clear active relations

DBCLEARRELATION() --> NIL

DBCLOSEALL() : 

Close all occupied workareas

DBCLOSEALL() --> NIL

DBCLOSEAREA() : 

Close a workarea

DBCLOSEAREA() --> NIL

DBCOMMIT() : 

Flush pending updates

DBCOMMIT() --> NIL

DBCOMMITALL() : 

Flush pending updates in all workareas

DBCOMMITALL() --> NIL

DBCREATE() : 

Create a database file from a database structure array

DBCREATE(<cDatabase>, <aStruct> [, <cDriver> ] ) --> NIL

DBCREATEIND() : 

Create an Index

   DBCREATEINDEX(<cIndexName>, <cKeyExpr>,
        [<bKeyExpr>], [<lUnique>]) --> NIL

DBDELETE() : 

Mark a record for deletion

DBDELETE() --> NIL

DBEDIT() : 

        Browse records in a table layout

    DBEDIT([<nTop>], [<nLeft>],
        [<nBottom>], <nRight>],
        [<acColumns>],
        [<cUserFunction>],
        [<acColumnSayPictures> | <cColumnSayPicture>],
        [<acColumnHeaders> | <cColumnHeader>],
        [<acHeadingSeparators> | <cHeadingSeparator>],
        [<acColumnSeparators> | <cColumnSeparator>],
        [<acFootingSeparators> | <cFootingSeparator>],
        [<acColumnFootings> | <cColumnFooting>]) --> NIL

DBEVAL() : 

Evaluate a code block for each record

DBEVAL(<bBlock>,
    [<bForCondition>],
    [<bWhileCondition>],
    [<nNextRecords>],
    [<nRecord>],
    [<lRest>]) --> NIL

DBF()* : 

Return current alias name

DBF() --> cAlias

DBFIELDINFO() : 

Return and optionally change information about a field

   DBFIELDINFO(<nInfoType>,

        <nFieldPos>,
        [<expNewSetting>]) --> uCurrentSetting

DBFILEGET() : 

Insert the contents of a field into a file

     DBFILEGET(<nFieldPos>, <cTargetFile>, <nMode>)
        --> lSuccess

DBFILEPUT() : 

Insert the contents of a file into a field

     DBFILEPUT(<nFieldPos>, <cSourceFile>)
        --> lSuccess

 DBFILTER() : 

Return the current filter expression as a character string

DBFILTER() --> cFilter

DBGOBOTTOM() : 

Move to the last logical record

DBGOBOTTOM() --> NIL

DBGOTO() : 

Move to a particular record

DBGOTO(<nRecordNumber>) --> NIL

DBGOTOP() : 

Move to the first logical record

DBGOTOP() --> NIL

DBINFO() : 

         Return and optionally change database file information

    DBINFO(<nInfoType>, [<expNewSetting>])
        --> uCurrentSetting

DBORDERINFO() :          Return and optionally change information about orders and index files

    DBORDERINFO(<nInfoType>,   [<cIndexFile>],
        [<cOrder> | <nPosition>],
        [<expNewSetting>]) --> uCurrentSetting

DBRECALL() : 

Reinstate a record marked for deletion

DBRECALL() --> NIL

DBRECORDINFO() :

         Return and optionally change information about a record

    DBRECORDINFO(<nInfoType>,
        [<nRecord>],
        [<expNewSetting>]) --> uCurrentSetting

DBREINDEX() :

         Recreate all active indexes for the current work area

    DBREINDEX() --> NIL

DBRELATION() :

Return the linking expression of a specified relation

DBRELATION( <nRelation> ) --> cLinkExp

DBRLOCK() :      

         Lock the record at the current or specified identity

    DBRLOCK([<xIdentity>]) --> lSuccess

DBRLOCKLIST()          Return an array of the current lock list

   DBRLOCKLIST() --> aRecordLocks

DBRSELECT() :

Return the target workarea number of a relation

DBRSELECT( <nRelation> ) --> nWorkArea

DBRUNLOCK()    

          Release all or specified record locks

    DBRUNLOCK([<xIdentity>]) --> NIL

DBSEEK() : 

Search for a key value

DBSEEK(<expKey>, [<lSoftSeek>]) --> lFound

DBSELECTAR() : 

Change the current workarea

DBSELECTAREA(<nArea> | <cAlias>) --> NIL

DBSETDRIVER() : 

Set the default database driver

DBSETDRIVER([<cDriver>]) --> cCurrentDriver

DBSETFILTER() : 

Set a filter condition

DBSETFILTER(<bCondition>, [<cCondition>]) --> NIL

DBSETINDEX()    

         Empty orders from an order bag into the order list

    DBSETINDEX(<cOrderBagName>) --> NIL

DBSETORDER()

Set the controlling order

    DBSETORDER(<nOrderNum>) --> NIL

DBSETRELAT() :

Relate two workareas

DBSETRELATION( <nArea> | <cAlias>, <bExpr>, [<cExpr>]) --> NIL

DBSKIP() : 

Move relative to the current record

DBSKIP([<nRecords>]) --> NIL

DBSTRUCT() : 

Create an array containing the structure of a database file

DBSTRUCT() --> aStruct

DBUNLOCK()

Release all locks for the current work area

    DBUNLOCK() --> NIL

DBUNLOCKALL()

Release all locks for all work areas

    DBUNLOCKALL() --> NIL

DBUSEAREA() : 

Use a database file in a workarea

DBUSEAREA( [<lNewArea>],
    [<cDriver>],
    <cName>,
    [<xcAlias>],
    [<lShared>],
    [<lReadonly>]) --> NIL

DELETED() : 

Return the deleted status of the current record

DELETED() --> lDeleted

EOF() : 

Determine when end of file is encountered

EOF() --> lBoundary

FCOUNT() : 

Return the number of fields in the current (.dbf) file

FCOUNT() --> nFields

FIELD() : 

Return a field name from the current (.dbf) file

    FIELD/FIELD(<nPosition>) --> cFieldName

FIELDBLOCK() :

Return a set-get code block for a field variable

FIELDBLOCK(<cFieldName>) --> bFieldBlock

FIELDGET() : 

Retrieve the value of a field using the ordinal position of the field in the database structure

FIELDGET(<nField>) --> ValueField

FIELDNAME() : 

Return a field name from the current (.dbf) file

FIELDNAME/FIELD(<nPosition>) --> cFieldName

FIELDPOS() : 

Return the position of a field in a workarea

FIELDPOS(<cFieldName>) --> nFieldPos

FIELDPUT() : 

Set the value of a field variable using the ordinal position of the field in the database structure

FIELDPUT(<nField>, <expAssign>) --> ValueAssigned

FIELDWBLOCK() : 

Return a set-get block for a field in a given workarea

FIELDWBLOCK(<cFieldName>, <nWorkArea>) --> bFieldWBlock

FLOCK() : 

Lock an open and shared database file

    FLOCK() –> lSuccess

FOUND() : 

Determine if the previous search operation succeeded

FOUND() --> lSuccess

HEADER() : 

Return the current database file header length

HEADER() --> nBytes

LASTREC() : 

Determine the number of records in the current (.dbf) file

LASTREC() | RECCOUNT()* --> nRecords

LUPDATE() : 

Return the last modification date of a (.dbf) file

LUPDATE() --> dModification

RECCOUNT()* : 

Determine the number of records in the current (.dbf) file

RECCOUNT()* | LASTREC() --> nRecords

RECNO() : 

Return the current record number of a work area

RECNO() --> nRecord

RECSIZE() : 

Determine the record length of a database (.dbf) file

RECSIZE() --> nBytes

RLOCK()

Lock the current record in the active work area

    RLOCK() --> lSuccess

SELECT() : 

Determine the work area number of a specified alias

SELECT([<cAlias>]) --> nWorkArea

USED() : 

Determine if a database file is in USE

USED() --> lDbfOpen

Hex View

Hexadecimal file viewer.

This is a experimental project with first intend of point out the power of Harbour and HMG. So, HexView is considerably slow on large files, please be patient.

Download here ( source only ).