Recital implements SQL-92 and most of the SQL-99 standard for SQL, but also provides lower level navigational data access for performing high transaction throughput. It is the choice of the application developer whether to use SQL, navigational data access, or a combination of both depending upon the type of application being developed.

If you have software packages which you wish to share with others or simply between your own personal machines, a neat and easy solution is to create your own YUM repository and provide your .repo file for download.
YUM is by far the easiest method of installing software on Red hat, Centos and Fedora. Not only does it mean you don't need to trawl the web looking for somewhere to download the packages, YUM does a great job of satisfying any package dependencies. As long as the required packages are available in the enabled repositories on your system, YUM will go out and get everything you need.
To create your own YUM repository, you will need to install the yum-utils and createrepo packages:
yum install yum-utils createrepo
yum-utils contains the tools you will need to manage your soon to be created repository, and createrepo is used to create the xml based rpm metadata you will require for your repository.
Once you have installed these required tools, create a directory in your chosen web server's document root e.g:
mkdir -p /var/www/html/repo/recital/updates
Copy the rpm's you wish to host into this newly created directory.
The next step is to create the xml based rpm metadata. To create this use the createrepo program we installed earlier.
At the shell type the following command:
createrepo -v -s md5 /var/www/html/repo/recital/updates
This will create the required metadata in the repodata directory of your /var/www/html/repo/recital/updates directory.
root@test repodata]# ls -l rwotal 44 -rw-r--r-- 1 root root 28996 Jan 13 21:42 filelists.xml.gz -rw-r--r-- 1 root root 284 Jan 13 21:42 other.xml.gz -rw-r--r-- 1 root root 1082 Jan 13 21:42 primary.xml.gz -rw-r--r-- 1 root root 951 Jan 13 21:42 repomd.xml
To do a final consistency check on your repository run the following command:
verifytree /var/www/html/repo/recital/updates
We now have a fully functioning YUM repository for our hosted rpm packages.
The next process is to create a .repo file in the client systems /etc/yum.repos.d directory.
Navigate to the /etc/yum.repos.d directory on your system as root.
Using your preferred text editor to create the .repo file. In this example I will call it recital.repo.
Now paste in the following lines:
[Recital] name=Recital Update Server baseurl=http://ftp.recitalsoftware.com/repo/recital/updates enabled=1 gpgcheck=1
Once that is saved, at the shell prompt on the same machine (YUM client system).
$ yum repolist Loaded plugins: presto, refresh-packagekit repo id repo name status Recital Recital Update Server enabled: 1 adobe-linux-i386 Adobe Systems Incorporated enabled: 17 fedora Fedora 12 - i386 enabled: 15,366
As you can see the Recital repo is now being picked up and we have access to all the packages it is hosting.
See how easy that was!
DB_SAMBA=YES ;export DB_SAMBA
preserve case = nodefault case = lowermangle case = yes
oplocks = False
share modes = no
This article talks about the log files available in Recital products and how to enable logging when required.
Overview
When discussing a problem with the Recital Support Team, one of the most common requests is that you enable logging and send them the log files produced. Log files along with error files are designed to provide detailed information about Recital processes and the prevailing environment and can be a fast-track to resolving a problem.
Log Files
There are three main types of log file:
- System Log
- Client/Server Communication Logs
- Custom Logs
System Log
The System log is a system-wide all product log. It tracks all login and logout operations from either Recital or the Recital Server. Logout details include the exit code: 0 for an error-free, 'normal' exit and the error number and message when an error has occurred. It also shows the licenses that have been loaded and any license error codes and messages. The system log filename is recital.log.
Client/Server Communication Logs
The Client/Server communication logs track the requests and responses between the Recital Server and its clients. The log files are as follows:
| Filename | Type | Description |
|---|---|---|
|
dbserver.log |
System-wide |
The Recital Server startup log. This logs any problems with the Recital Server startup. |
|
port.log |
System-wide |
The port listener log. The port listener (or portserver) listens on port 8001 for client connection requests and spawns the appropriate server process. |
|
net.log |
Connection |
The netserver log. The netserver is the Recital Server database and 4GL engine. |
|
rsi.log |
Connection |
The Recital Server Interface (RSI) Gateway log. This logs communication with the Database Gateways to SQL databases. |
|
rec.log |
Connection |
The Recital Database Gateway log. The Recital Database Gateway (or recserver) is the SQL database engine for Recital Gateway data access. |
|
mys.log |
Connection |
The MySQL Database Gateway log. |
|
ora.log |
Connection |
The Oracle Database Gateway log. |
|
inf.log |
Connection |
The Informix Database Gateway log. |
|
ing.log |
Connection |
The Ingres Database Gateway log. |
|
pos.log |
Connection |
The PostgreSQL Database Gateway log. |
|
jdb.log |
Connection |
The JDBC Driver Database Gateway log. |
Custom Logs
The Recital/4GL USERLOG() function can be used to log information to a user-specific log file for debugging or audit trail purposes. For full information on this function, please see the USERLOG() documentation.
Enabling Log Files
For instructions on enabling log files for individual products, please follow these links:
- Recital Server for Windows
- Recital Server for Linux
- Recital Server for UNIX
- Recital Server for OpenVMS
- Recital for Linux
- Recital for UNIX
- Recital for OpenVMS
Enabling Log Files: Recital Server for Windows
To enable the system log file for the Recital Universal Application Server for Windows, include the following command in the UAS\config.db file:
set syslogging on
The Recital Server Manager System Logging tab allows for the viewing and resetting of the System log.
Section
Item
Description
System Logging
DateTime
Date and time stamp of the action.
Name
Login name used by connection
Action
Action logged: Login, Logoff, Errot
Details
Details of action
Buttons
Purge
Allows the log file to be reset
Refresh
Refreshes the display
To set up Client/Server logging, use the Recital Server Manager Settings tab to update the server's Registry entries:
The following Log file settings can be configured:
|
Item |
Description |
|---|---|
|
Log files Directory Path |
Enter the directory in which log files will be created. The default is the UAS\log directory. |
|
Enabled |
Check to enable log file creation. |
|
Versions |
Check to enable log file versioning. |
|
Listener |
Click to view the current port listener log file |
|
Server |
Click to view the current netserver log file |
|
Purge |
Click to purge all log files |
Enabling Log Files: Recital Server for Linux
To enable the system log file for the Recital Server for Linux, include the following command in the conf/config.db file:
set syslogging on
To set up Client/Server logging, the Recital Server can be started with the 'logging' parameter, in which case, all relevant logging will take place.
# service startup logging<
Alternatively, one or more of the following environment variables can be added to the dbserver.conf file or set at the Operating System prompt. The Recital Server must be restarted before environment variable changes will be recognized. Each environment variable should be set to the name of a log file.
Environment Variable
Logs Activity of...
UASLOG_PORT
Port Server (db_rsiserver)
UASLOG_NET
(Net) Server (db_netserver)
UASLOG_ORA
Oracle Server (db_oraserver)
UASLOG_INF
Informix Server (db_infserver)
UASLOG_ING
Ingres Server (db_ingserver)
UASLOG_JDB
JDBC Server (db_jdbserver)
UASLOG_REC
Recital Server (db_recserver)
Extract from recital.conf:
UASLOG_PORT="port.log" ; export UASLOG_PORT UASLOG_NET="net.log" ; export UASLOG_NET UASLOG_ORA="ora.log" ; export UASLOG_ORA UASLOG_INF="inf.log" ; export UASLOG_INF UASLOG_ING="ing.log" ; export UASLOG_ING UASLOG_JDB="jdb.log" ; export UASLOG_JDB UASLOG_REC="rec.log" ; export UASLOG_REC
DB_LOGDIR
If the environment variable DB_LOGDIR is set to an existing directory, all log files will be written to this directory. If not, the log files will be created in the bin directory.
DB_LOGDIR is set in the conf/recital.conf file. By default it is set to the log directory:
DB_LOGDIR=${ROI_ROOT}log/ ; export DB_LOGDIR
DB_LOGVER
If the environment variable DB_LOGVER is greater than 0, version numbers are added to the file names. For example, the activity of the first Net Server process will be logged to net.log, the second to net001.log, the third to net002.log etc. up to the maximum value of DB_LOGVER.
DB_LOGVER is set in the conf/recital.conf file:
DB_LOGVER=10; export DB_LOGVER
Enabling Log Files: Recital Server for UNIX
To enable the system log file for the Recital Server for UNIX, include the following command in the conf/config.db file:
set syslogging on
To set up Client/Server logging, the Recital Server can be started with the 'logging' parameter, in which case, all relevant logging will take place.
# service startup logging
Alternatively, one or more of the following environment variables can be added to the <em>dbserver.conf</em> file or set at the Operating System prompt. The Recital Server must be restarted before environment variable changes will be recognized. Each environment variable should be set to the name of a log file.
Environment Variable
Logs Activity of...
UASLOG_PORT
Port Server (db_rsiserver)
UASLOG_NET
(Net) Server (db_netserver)
UASLOG_ORA
Oracle Server (db_oraserver)
UASLOG_INF
Informix Server (db_infserver)
UASLOG_ING
Ingres Server (db_ingserver)
UASLOG_JDB
JDBC Server (db_jdbserver)
UASLOG_REC
Recital Server (db_recserver)
Extract from recital.conf:
UASLOG_PORT="port.log" ; export UASLOG_PORT UASLOG_NET="net.log" ; export UASLOG_NET UASLOG_ORA="ora.log" ; export UASLOG_ORA UASLOG_INF="inf.log" ; export UASLOG_INF UASLOG_ING="ing.log" ; export UASLOG_ING UASLOG_JDB="jdb.log" ; export UASLOG_JDB UASLOG_REC="rec.log" ; export UASLOG_REC
DB_LOGDIR
If the environment variable DB_LOGDIR is set to an existing directory, all log files will be written to this directory. If not, the log files will be created in the bin directory.
DB_LOGDIR is set in the conf/recital.conf file. By default it is set to the log directory:
DB_LOGDIR=${DB_ROOT}log/ ; export DB_LOGDIR
DB_LOGVER
If the environment variable DB_LOGVER is greater than 0, version numbers are added to the file names. For example, the activity of the first Net Server process will be logged to net.log, the second to net001.log, the third to net002.log etc. up to the maximum value of DB_LOGVER.
DB_LOGVER is set in the conf/recital.conf file:
DB_LOGVER=10; export DB_LOGVER
Enabling Log Files: Recital Universal Application Server for OpenVMS
To enable the system log file for the Recital Universal Application Server for OpenVMS, include the following command in the db_uas:config.db file:
set syslogging on
To set up Client/Server logging, one or more of the following symbols can be added to the <em>db_uas:login.com</em> file. The Recital Server must be restarted before symbol changes will be recognized. Each symbol should be set to the name of a log file.
Symbol
Logs Activity of…
UASLOG_PORT
Port Server (db_rsiserver)
UASLOG_NET
(Net) Server (db_netserver)
UASLOG_ORA
Oracle Server (db_oraserver)
UASLOG_INF
Informix Server (db_infserver)
UASLOG_ING
Ingres Server (db_ingserver)
UASLOG_JDB
JDBC Server (db_jdbserver)
UASLOG_REC
Recital Server (db_recserver)
Extract from db_uas:login.com
$ uaslog_port :== port.log $ uaslog_net :== net.log $ uaslog_ora :== ora.log $ uaslog_inf :== inf.log $ uaslog_ing :== ing.log $ uaslog_jdb :== jdb.log $ uaslog_rec :== rec.log
DB_LOGDIR
If the symbol DB_LOGDIR is set to an existing directory, all log files will be written to this directory. If not, the log files will be created in the UAS directory.
DB_LOGDIR is set in the db_uas:login.com file. By default it is set to the UAS.log] directory:
$db_logdir :== 'db_root'.log] ! system logging directory
DB_LOGVER
If the symbol DB_LOGVER is enabled, version numbers are added to the file names. For example, the activity of the first Net Server process will be logged to net.log, the second to net001.log, the third to net002.log etc.
DB_LOGVER is set in the db_uas:login.com file:
$db_logver :== true ! enable multiple log files
Enabling Log Files: Recital for Linux
To enable the system log file for Recital for Linux, include the following command in the conf/config.db file:
set syslogging on
Enabling Log Files: Recital for UNIX
To enable the system log file for Recital for UNIX, include the following command in the conf/config.db file:
set syslogging on
Enabling Log Files: Recital for OpenVMS
To enable the system log file for Recital for OpenVMS, include the following command in the db_ovd:config.db file:
set syslogging on
In Brief
- Log files provide important information to aid problem resolution, but they are also an overhead, so logging should only be enabled when required, not in normal production operation.
- The System log provides a system-wide view of logins, exits and error codes.
- The System log can be viewed in table format via the SYSLOGGING System Table.
- The System log is enabled using the SET SYSLOGGING ON Recital/4GL command in the conf/config.db file.
- Client/Server logs provide detailed information on client/server requests and responses.
- Client/Server logs are enabled using environment variables, symbols or Registry entries or by specifying the 'logging' parameter when starting the Recital Server.
- The location of log files is determined by the DB_LOGDIR setting.
- Versioning of log files is determined by the DB_LOGVER setting.
Overview
file which contains information, including full path details, about all the files that belong to that particular database. Opening a database gives an application access to all that database's files - operating system and data dictionary protection and security permitting - in whichever directory on the system they reside and database commands can target the files as a single unit.NOTE: The word 'database' has often been used in Xbase products to refer to an individual '.dbf' file. In this article these are referred to as 'tables' and a database may contain many tables.
Advantages
Recital has always offered developers the maximum in flexibility in the design and deployment of their applications. The SET DEFAULT and SET PATH commands along with the ability to access files via their full Operating System path name has allowed data and code to be created and stored in any required location. Such flexibility does however put the onus on the developer to manage all elements of the application and ensure that maintenance tasks cover all files. The introduction of the database commands retains the established developer-driven design, but provides functionality to facilitate the access and maintenance of the components of that design. The functionality offered is in three main areas:- Facilitate data access
- Facilitate the storage and extraction of information about the files in an application
- Facilitate the maintenance of the files in an application
These three areas are looked at in more detail in the sections below.
Data Access
The immediate effect of using a database is that all the database's tables and associated files (indexes, dictionaries, memo files) are accessible with the issue of a single command, the OPEN DATABASE command.// Open the database
> open database southwind
// List the database tables
> list tables
Tables in Database southwind:
Name Source
categories /usr/recital/data/southwind/categories.dbf
customers /usr/recital/data/southwind/customers.dbf
employees /usr/recital/data/southwind/employees.dbf
example /usr/recital/data/southwind/example.dbf
order_details /usr/recital/data/southwind/order_details.dbf
orders /usr/recital/data/southwind/orders.dbf
productsbyname /usr/recital/data/southwind/productsbyname.dbf
products /usr/recital/data/southwind/products.dbf
shippers /usr/recital/data/southwind/shippers.dbf
suppliers /usr/recital/data/southwind/suppliers.dbf
cisamdemo /usr/recital/data/southwind/cisamdemo.dbf
/ Open a tableIn the case of the sample southwind database that ships with Recital products on all platforms and is shown above, this effect can be achieved in other ways (SET PATH or SET DEFAULT), since its files all reside in the southwind directory. The database advantage comes when the database catalog contains files from multiple directories, e.g.
> use example
// Open the database
> open database myapp
// List the database tables
> list tables
Tables in Database myapp:
Name Source
zipcodes /usr/myapp/data/lookups/zipcodes.dbf
customers /usr/myapp/data/current/customers.dbf
archive03 /usr/myapp/data/archive/archive03.dbf
archive04 /usr/myapp/data/archive/archive04.dbf
users /usr/allapps/data/users.dbf
menus /usr/myapp/data/system/menus.dbf
// Open a tableThe OPEN DATABASE command requires only the database name to be specified, not the complete path of a directory as with SET PATH or SET DEFAULT. Databases are searched for in the sub-directories of the directory defined in the DB_DATADIR environment variable or symbol. DB_DATADIR is set in the system wide configuration file.
> use users
#---------------------------------------------------NOTE: DB_DATADIR is read from these files at startup to determine the home directory for databases. Updates to DB_DATADIR once a Recital process is running do not change this setting. The OPEN DATABASE command and certain other database commands allow a '?' to be specified in place of a database name. In this case the 'Select a file' dialog is displayed, listing the available files in the DB_DATADIR directory.
# location of directories and important files
#---------------------------------------------------
DB_DATADIR="${ROI_ROOT}data/" ;export DB_DATADIR
Click image to display full sizeFig 1: Recital Terminal Developer OPEN DATABASE ? command.
This functionality is also supported by the PACK DATABASE, REBUILD DATABASE and REINDEX DATABASE commands.
Databases can also simplify data access for Recital Client Drivers using the Recital Database Server: instead of specifying a starting directory, only a database name is required. The database can handle files from multiple directories and associate tables with their single index files.
Recital Universal .NET Data Provider
/////////////////////////////////////////
// include the references below
using System.Data;
using Recital.Data;
/////////////////////////////////////////
// sample code to call a Stored Procedure
public int CallStoredProcedure()
{
string source = "Data Source=localhost;" +
"Database=southwind;" +
"uid=?;"+
"pwd=?";
RecitalConnection conn = new RecitalConnection(source);
...
Recital Universal JDBC Driver
import java.sql.*;
import java.io.*;
import java.net.URL;
import java.math.BigDecimal;
import Recital.sql.*;
public class jdbc_test {
public static void main(String argv[]) {
int i;
ResultSet rs;
ResultSetMetaData rsmd;
System.out.println("Recital JDBC driver verification.");
for (int ii=0; ii<1; ++ii) {
try {
//----------------------------------------------------------
//-- Load the Client Driver for the
//-- Recital Universal Application Server
//----------------------------------------------------------
System.out.println("Loading Recital JDBC driver.");
new RecitalDriver();
//-----------------------------------------------------------
//-- The standard format of the connection URL is as follows:
//-----------------------------------------------------------
String url = "jdbc:Recital:" +
"SERVERNAME=?;" +
"DATABASE=jdbc_test;" +
"USERNAME=?;" +
"PASSWORD=?;" +
"ENCRYPTION=false";
...
Windows Recital Universal ODBC Driver
Click image to display full sizeFig 2: Recital Universal ODBC Driver DSN setup using a database.
Database Procedure Libraries
A database can have an associated procedure library, which is automatically opened when the database is opened. This way, any procedures required by the database's data files are always available. The procedure library should reside in the database's directory and be named dbc_xxx_library.prg, where 'xxx' is the name of the database. When the OPEN DATABASE command is issued, a check is made for the database procedure library and a SET PROCEDURE TO dbc_xxx_library.prg ADDITIVE issued automatically. The procedure library is in turn closed when the CLOSE DATABASES command is issued. This is particularly convenient for client/server database access.Database Events
Issuing the OPEN DATABASE or CLOSE DATABASES command also fires a database event. Database events, like triggers for tables and forms, can have programs associated with them. The OPEN DATABASE command fires the DBC_OPENDATA event and will run a program called db_opendata.prg if one exists in the database's directory. Similarly, the CLOSE DATABASES command fires the DBC_CLOSEDATA event and runs the db_closedata.prg program. Both of these events also allow the current open or close operation to be abandoned if the associated program returns a logical false (.F.).Information
Databases, specifically database catalogs, are an excellent place to store information about the files required by a particular application. Instead of having to search through application code to determine which tables are being used and what index keys they have, this information can be viewed in the database catalog. Database catalogs are themselves Recital tables and can be viewed and/or updated in the same way as any other Recital table. There is also a series of commands to provide information about the currently open database. DISPLAY/LIST DATABASE The DISPLAY DATABASE and LIST DATABASE commands display the database name and path, followed by the equivalent of LIST STRUCTURE INDEX and LIST DICTIONARY for each table in the database, e.g.> open database southwind
> display database
Database Name: southwindDISPLAY DATABASE shows the data one screen at a time, whereas LIST DATABASE is ideal for output to a file.
Database Path: /usr/recital-9.0/data/southwind/
Structure for database : categories.dbf
Number of data records : 8
Date of creation : 05/12/2004
Date of last update : 05/12/2004
Database encrypted : False
Field Field Name Type Width Dec Description 1 CATEGORYID Numeric 10 Category ID 2 CATEGORYNAME Character 15 Category Name 3 DESCRIPTION Memo 8 Description 4 PICTURE Memo 8 Picture ** Total ** 42
Production DBX file: categories.dbx
Master Index TAG: CATEGORYID
Key: categoryid
Type: Binary
Len: 8
...
> open database southwind
> list database to file info.txt
DISPLAY/LIST TABLES
LIST TABLES, as we have seen above, lists all the tables from the database, giving each table's name and path. DISPLAY TABLES shows the information one screen at a time.Maintenance
Using a database can simplify the maintenance of an application's programs, tables and indexes. Multiple files, possibly in different directories, can be targeted by a single database command.COMPILE DATABASE
The COMPILE DATABASE command can be used to issue a COMPILE command for all program files listed in the database catalog.// Open the databaseNOTE: Program files are added to a database using the SQL CREATE PROCEDURE command.
open database myapp
// Compile all the database's programs
compile database
PACK DATABASE
The PACK DATABASE command issues a PACK command for every table in the database catalog. The PACK command is used to permanently remove any records that have been marked for deletion using the DELETE command.// Open the database
open database southwind
// Pack all the database's tables
pack database
REINDEX DATABASE
The REINDEX DATABASE command rebuilds all the tag and single indexes in the catalog. This is the equivalent of an INDEX ON <key> TO | TAG <index> for each catalogued index key.// Open the databaseNOTE: Using a database helps protect against a table being opened without its associated single index files also being opened. Any single index files that are included in the database catalog will automatically be opened when their table is opened via the database. If a single index appears in the database catalog, but the physical file no longer exists, it will be removed from the catalog when its associated table is next opened. All indexes, tagged indexes or single indexes, created while the database is open, are added automatically to the database catalog.
open database southwind
// Rebuild all the database's indexes
reindex database
REBUILD DATABASE
The REBUILD DATABASE command is used to PACK, rebuild the index tags and refresh the contents of the database catalog file.// Rebuild the database
rebuild database southwind
Creating and populating a database
Databases are created using the CREATE DATABASE command.// Create new databaseThe CREATE DATABASE creates a sub-directory in the DB_DATADIR and initializes the new database's catalog file. The catalog file is given the same basename as the database and is a Recital table with a '.cat' file extension. It has a production index file with a '.cax' file extension and a memo file with a '.cam' file extension.
create database newdb
// Open the databaseWith the database open, the catalog file table is opened in the highest available workarea and is given an alias name of its basename preceded by an underscore, e.g. '_newdb'. Any new tables or indexes that are created will be automatically added into the catalog and form part of the database. 'Free' tables can also be manually added into a database using the SQL ADD TABLE command.
open database newdb
// config.dbAs the application runs, 'myapp' in the example above, each table that is opened is added to the database catalog. Indexes that are opened are added in the same way. Using SET AUTOCATALOG OFF, inclusion in the catalog can be restricted. Once all required areas of the application have been catalogued, the application can be updated to make use of the database commands.
set sql on
set sql to vfp
// end of config.db
// Create a 'free' table, with no database open
create table free1 (field1 char(10), field2 date)
// Open the database
open database newdb
add table free1
Converting an existing application
The AUTOCATALOG commands can be used to automatically create a database catalog based on an existing application. The SET AUTOCATALOG TO >database< command will create the database if it does not already exist.// Database must be closed during autocatalog process
close databases
// Specify the database
set autocatalog to myappdb
// Start the autocatalog process
set autocatalog on
do myapp
// The autocatalog process can be toggled off to exclude
// certain parts of the application if required
// set autocatalog off
Exporting a database
The BACKUP DATABASE and RESTORE DATABASE commands have been added to simplify the process of moving applications between binary incompatible platforms. Binary files such as tables, memo files and data dictionaries must be exported to ASCII format to allow them to be transferred from one platform to another where the platforms have different binary ordering. For example, this is the case when moving files between a SUN Sparc Solaris machine and an Intel Linux machine. The BACKUP DATABASE and RESTORE DATABASE commands are extensions of the BUILD and INSTALL commands: where BUILD and INSTALL operate on a specified list of tables, BACKUP DATABASE and RESTORE DATABASE automatically handle an entire database.// Open the databaseThe BACKUP DATABASE command goes through the database catalog, exporting each file into an ASCII format that can be handled by the RESTORE DATABASE command. The files are created in a directory with the same name as the database. This directory is a sub-directory of the directory specified in the environment variable DB_BACKUPDIR and is created automatically. By default, DB_BACKUPDIR is the 'backup' sub-directory of the Recital home directory.
open database southwind
// Export the database to ASCII format
backup database
// Query the DB_BACKUPDIR environment variable settingLike DB_DATADIR, DB_BACKUPDIR is set in the system-wide configuration file and is read at startup to determine the home directory for database backups. Updates to DB_BACKUPDIR once a Recital process is running do not change this setting.
> ? getenv([DB_BACKUPDIR])
/usr/recital/backup
# profile.db/uas extractOnce the BACKUP DATABASE command has completed, the files can be transferred to another platform, for example from Intel SCO OpenServer to IBM AIX and the RESTORE DATABASE command used to recreate the database.
#---------------------------------------------------
# location of directories and important files
#---------------------------------------------------
DB_BACKUPDIR="${ROI_ROOT}backup/" ;export DB_BACKUPDIR
// Export the database to ASCII format
// Note: the BACKUP DATABASE command operates
// on the active or specified database
$ db
> backup database southwind
> quit
// 'tar' up the files for transfer
$ cd /usr/recital/backup
$ tar cvf southwind.tar ./southwind
// Transfer the tar archive to DB_BAKUPDIR on the
// target machine, then extract the files
$ pwd
/usr/recital/backup
$ tar xvf southwind.tar
// Rebuild the database on the target platform
// The database is automatically created
// as a sub-directory of DB_DATADIR
$ db
> restore database southwind
Binary distributions for Unison can be found here.
The user manual can be found here.
In this article Barry Mavin, CEO and Chief Software Architect for Recital, details how to work with Triggers in the Recital Database Server.
Overview
A trigger is a special kind of stored procedure that runs when you modify data in a specified table using one or more of the data modification operations: UPDATE, INSERT, or DELETE.
Triggers can query other tables and can include complex SQL statements. They are primarily useful for enforcing complex business rules or requirements. For example, you can control whether to allow a new order to be inserted based on a customer's current account status.
Triggers are also useful for enforcing referential and data integrity.
Triggers can be used with any data source that is handled natively by the Recital Database Engine. This includes Recital, FoxPro, FoxBASE, Clipper, dBase, CISAM, and RMS data,
Creating and Editing Triggers
To create a new Trigger, right-click the Procedures node in the Databases tree of the Project Explorer and choose Create. To modify an existing Trigger select the Trigger in the Databases Tree in the Project Explorer by double-clicking on it, or select Modify from the context menu. By convertion we recommend that you name your Stored Procedures beginning with "sp_xxx_", user-defined functions with "f_xxx_", and Triggers with "dt_xxx_", where xxx is the name of the table that they are associated with.
Associating Triggers with a Table
Once you have written your Triggers as detailed above you can associate them with the operations performed on a Table by selecting the Table tab.
The Tables tab allows you to select a Trigger procedure by clicking on the small button at the right of the Text field.
Types of Triggers
As can be seen from the Tables tab detailed below, The Recital Database Server handles 6 distinct types of Triggers.
Open Trigger
The Open Trigger is called after is a table is opened but before any operations are performed on it. You can use this trigger to record a log of table usage or provide a programmable means of checing security. If the Trigger procedure returns .F. (false), then the table is not opened. You can use a TRY...CATCH block around the associated command to inform the user.
Close Trigger
The Close Trigger is called just prior to a table being closed. In this trigger you may find it useful to get transaction counts by using the IOSTATS() built-in 4GL function, and record these values in a transaction log.
Update Trigger
The Update Trigger is called prior to a record update operation being performed. You can use this trigger to perform complex application or data specific validation. If the Trigger procedure returns .F. (false), then the record is not updated. You can use inform the user from within the Trigger procedure the reason that the data cannot be updated.
Delete Trigger
The Delete Trigger is called prior to a record delete operation being performed. You can use this trigger to perform complex application or data specific validation such as cross-table lookups e.g. attempting to delete a customer recortd when there are still open orders for that specific customer. If the Trigger procedure returns .F. (false), then the record is not deleted.
Insert Trigger
The Insert Trigger is called prior to a record insert (append) operation being performed. You can use this trigger to perform such tasks as setting up default values of columns within the record. If the Trigger procedure returns .F. (false), then the record is not inserted.
Rollback Trigger
The RollbackTrigger is called prior to a rollback operation being performed from within a form. If the Trigger procedure returns .F. (false), then the record is not rolled back to its original state.
Testing the Trigger
To test run the Trigger, select the Trigger in the Databases Tree in the Project Explorer by double-clicking on it. Once the Database Administrator is displayed, click the Run button to run the Trigger.
APPEND FROM TYPE CSV <file-name.csv>The TYPE keyword has now been enhanced to support a comma separated values (CSV) format
When installing nomachine on redhat 5.3 64-bit be sure to:
- Make sure you have installed the 64-bit packages as the 32-bit ones will not work.
- add the hostname to /etc/hosts
- Check "Disable encryption of all traffic" (in configuration / advanced tab)
- add the hostname to /etc/hosts
- make sure the host IP is not specified as 127.0.0.1 line
- Uncheck "Disable encryption of all traffic" (in configuration / advanced tab)
// declare some simple procedures
proc display(cArg)
echo "display=" + cArg
endproc
proc show(cArg)
echo "show=" + cArg
endproc
// create an object based on an anonymous class
myobj = new object()
// add some properties
myobj["name"] = "barry"
myobj["company"] = "recital"
// now declare an anonymous method
myobj["mymethod"] = display
// call the method
myobj.mymethod("hello world") // displays "display=hello world"
// redeclare the method
myobj["mymethod"] = show
// call the method
myobj.mymethod("hello world") // displays "show=hello world"
Where this becomes particularly useful is when you have a procedure that calls anonymous methods in order to process data. This technique can be used to call anonymous procedures in your code.
proc processdata(oArg)
oArg.mymethod(oArg.name)
endproc
proc show(cArg)
echo "show=" + cArg
endproc
myobj = new object()
myobj["name"] = "barry"
myobj["mymethod"] = show
processdata(myobj) // displays "show=barry"