// 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"
$ lsof | grep db.exe | grep accounts db.exe 16897 john 6uw REG 253,0 20012 3413872 /usr/recital100/qa/accounts.dbf db.exe 16897 john 7u REG 253,0 4176 3413885 /usr/recital100/qa/accounts.dbxIf you want to check for locks you can use lslk, for example;
$ lslk | grep db.exe | grep accounts db.exe 16897 253,0 3413872 20012 w 0 0 0 12319 0 /usr/recital100/qa/accounts.dbfIf you don't have lslk installed you can install it with one of the updaters, for example on redhat linux:
$ yum update lslk
This article discusses the features in Recital that allow data to be imported and exported between platforms in Microsoft® ADO XML Format.
Overview
Extensible Markup Language, XML, is widely regarded as a lingua franca for the interchange of data. XML's text-based, platform-independent format and its integration of data and the schema to define and describe that data, make it the ideal import/export medium. Recital software provides the functionality to output the data from Recital - and other supported table formats such as FoxPro and FoxBASE - into XML file format and to import XML data into those tables' formats. Such import/export operations provide the means to exchange data with third-party applications and can also facilitate the transfer of data between Recital installations on binary-incompatible platforms.
The features examined in this article are available in Recital Terminal Developer and in the Recital Mirage and Recital Database Servers on all Recital supported platforms. Both the Recital/4GL and Recital/SQL provide XML import and export capabilities. The XML files discussed are in Microsoft® ADO XML format.
Microsoft® ActiveX® Data Objects XML Format
The ADO XML format is primarily designed for ADO Recordset persistence and ADO XML files created by Recital can be used in this way and loaded directly into ADO Recordsets. The format can, though also be used for more generic data transfer. An ADO XML file is self-contained, consisting of two sections: a schema section followed by a data section. The schema conforms to the W3C XML-Data specification and defines the data structure.
For additional information on the Microsoft® ActiveX® Data Objects XML Format, please see Appendix 1.
NOTE: The Recital XMLFORMAT setting should always be in its default setting of ADO for ADO XML Format operations.
set xmlformat to ADO
SQL
Recital/SQL offers the ability to export data into XML files using the SELECT and FETCH statements and import from XML using the CREATE TABLE and INSERT statements.
SQL: Exporting
The SELECT...SAVE AS XML statement allows the complete result set from a SELECT statement to be saved as an XML file. This could be a complete table:
open database southwind SELECT * from orders SAVE AS XML orders.xml
or a more complex multi-table query:
open database southwind SELECT orders.orderid, orders.customerid,; employees.employeeid, employees.lastname, employees.firstname,; orders.orderdate, orders.freight, orders.requireddate,; orders.shippeddate, orders.shipvia, orders.shipname,; orders.shipaddress, orders.shipcity,; orders.shipregion, orders.shippostalcode, orders.shipcountry,; customers.companyname, customers.address, customers.city,; customers.region, customers.postalcode, customers.country; FROM orders INNER JOIN customers; ON customers.customerid = orders.customerid,; orders INNER JOIN employees; ON orders.employeeid = employees.employeeid; SAVE AS XML orderinfo
The resulting XML file can then be further processed within the same or a different Recital environment or transferred to a third party product.
<x-ml xmlns:z="#RowsetSchema" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3- 00AA00C14882"> <s:schema id="RowsetSchema"> <s:elementtype rs:updatable="true" content="eltOnly" name="row"> <s:attributetype rs:basecolumn="orderid" rs:basetable="orders.dbf" rs:write="true" rs:nullable="true" rs:number="1" name="orderid"> <s:datatype rs:fixedlength="true" rs:precision="14" rs:scale="0" dt:maxlength="10" rs:dbtype="numeric" dt:type="number"> </s:datatype></s:attributetype> <s:attributetype rs:basecolumn="customerid" rs:basetable="orders.dbf" rs:write="true" rs:nullable="true" rs:number="2" name="customerid"> <s:datatype rs:fixedlength="true" dt:maxlength="5" rs:dbtype="str" dt:type="string"> </s:datatype></s:attributetype> <s:attributetype rs:basecolumn="employeeid" rs:basetable="orders.dbf" rs:write="true" rs:nullable="false" rs:number="3" name="employeeid"> <s:datatype rs:fixedlength="true" rs:precision="20" rs:scale="0" dt:maxlength="10" rs:dbtype="numeric" dt:type="number"> </s:datatype></s:attributetype> <s:attributetype rs:basecolumn="lastname" rs:basetable="orders.dbf" rs:write="true" rs:nullable="false" rs:number="4" name="lastname"> <s:datatype rs:fixedlength="true" dt:maxlength="20" rs:dbtype="str" dt:type="string"> </s:datatype></s:attributetype> <s:attributetype rs:basecolumn="firstname" rs:basetable="orders.dbf" rs:write="true" rs:nullable="false" rs:number="5" name="firstname"> <s:datatype rs:fixedlength="true" dt:maxlength="10" rs:dbtype="str" dt:type="string"> </s:datatype></s:attributetype> <s:attributetype rs:basecolumn="orderdate" rs:basetable="orders.dbf" rs:write="true" rs:nullable="true" rs:number="6" name="orderdate"> <s:datatype rs:fixedlength="true" dt:maxlength="10" rs:dbtype="Date" dt:type="Date"> </s:datatype></s:attributetype> <s:attributetype name="freight" ...
Click image to display full size
Fig 1: Microsoft® Office Excel 2003: orderinfo.xml.
For data accessed through a Recital Database Gateway, such as Oracle, MySQL or PostgreSQL, the FETCH command can be used to save a cursor results set into an XML file:
// Connect to MySQL Database 'mydata' via Recital Database Gateway nStatHand=SQLSTRINGCONNECT("mys@mysql1:user1/pass1-mydata",.T.) if nStatHand < 1 dialog box [Could not connect] else DECLARE cursor1 CURSOR FOR; SELECT account_no, last_name, first_name FROM example OPEN cursor1 FETCH cursor1 INTO XML exa1.xml SQLDISCONNECT(nStatHand) endif
SQL: Importing
The CREATE TABLE statement allows a new table to be created based on the structure defined in an XML file. The data from the XML file can optionally be loaded into this new table if the LOAD keyword is included. For example, a new 'orderinfo' table can be created and populated with data from the orderinfo.xml file created by the SELECT...SAVE AS XML statement shown earlier:
open database southwind SELECT orders.orderid, orders.customerid,; employees.employeeid, employees.lastname, employees.firstname,; orders.orderdate, orders.freight, orders.requireddate,; orders.shippeddate, orders.shipvia, orders.shipname,; orders.shipaddress, orders.shipcity,; orders.shipregion, orders.shippostalcode, orders.shipcountry,; customers.companyname, customers.address, customers.city,; customers.region, customers.postalcode, customers.country; FROM orders INNER JOIN customers; ON customers.customerid = orders.customerid,; orders INNER JOIN employees; ON orders.employeeid = employees.employeeid; SAVE AS XML orderinfo CREATE TABLE orderinfo FROM XML orderinfo LOAD
The INSERT statement can be used to load data when the table structure already exists. Taking our earlier orderinfo.xml file again, the data can be loaded using INSERT:
open database southwind; SELECT orders.orderid, orders.customerid,; employees.employeeid, employees.lastname, employees.firstname,; orders.orderdate, orders.freight, orders.requireddate,; orders.shippeddate, orders.shipvia, orders.shipname,; orders.shipaddress, orders.shipcity,;; orders.shipregion, orders.shippostalcode, orders.shipcountry,; customers.companyname, customers.address, customers.city,; customers.region, customers.postalcode, customers.country; FROM orders INNER JOIN customers; ON customers.customerid = orders.customerid,; orders INNER JOIN employees; ON orders.employeeid = employees.employeeid; SAVE AS XML orderinfo CREATE TABLE orderinfo FROM XML orderinfo INSERT INTO orderinfo FROM XML orderinfo
The examples above show the export and import in a single piece of code. To transfer data between binary-incompatible platforms, the export phase using SELECT...SAVE AS XML would be carried out on the source platform, the resulting XML file would be transferred to the target platform, then the import phase using CREATE TABLE...LOAD or CREATE TABLE + INSERT would be run on the target platform.
Recital/4GL
The Recital/4GL offers the ability to export data into XML files using the COPY TO ... TYPE XML command and import from XML using the XMLFIRST() and XMLNEXT() functions.
Recital/4GL: Exporting
The COPY TO command can be used to export data from Recital and other natively supported tables out to a wide range of formats. This includes exporting to an XML file. The '.xml' file extension is added automatically. The COPY TO command can be used to export an entire table:
open database southwind use orders copy to orders type xml
or, using the FIELDS clause and the FOR or WHILE clauses, restrict the field list and export only those records which match a particular condition:
open database southwind use orders copy to orders type xml fields orderid for year(orderdate) = 1996
Only the orderid field from those records which match the condition is exported:
<x-ml xmlns:z="#RowsetSchema" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3- 00AA00C14882"> <s:schema id="RowsetSchema"> <s:elementtype rs:updatable="true" content="eltOnly" name="row"> <s:attributetype rs:basecolumn="ORDERID" rs:basetable="ORDERS" rs:write="true" rs:nullable="true" rs:number="1" name="ORDERID"> <s:datatype rs:fixedlength="true" rs:precision="10" rs:scale="0" dt:maxlength="10" rs:dbtype="numeric" dt:type="number"> </s:datatype></s:attributetype> </s:elementtype> </s:schema> <rs:data> <z:row orderid="10248"> <z:row orderid="10249"> <z:row orderid="10250"> <z:row ...
Recital/4GL: Importing
Data from an XML file can be extracted one record at a time using the XMLFIRST() and XMLNEXT() functions. XMLFIRST() reads the first record from an XML file and loads information from the file into a series of memory variables and arrays. The record data is loaded into a one-dimensional array which is created automatically. Each element in the array contains the data for its corresponding field in string format. The field names are loaded into another automatically-created array. The XMLNEXT() function works in a similar way to deal with all the subsequent records in the XML file. The XMLCOUNT() function can be used, as in the example below, to determine how many data records the XML file has.
The Recital/4GL includes a vast range of functions for manipulation and conversion of arrays and their individual elements. In the example program below, the XMLFIRST() and XMLNEXT() functions are used to sequentially extract each record from an XML file, whose name is passed to the program as a parameter. Once loaded into an array, the data is converted to the correct Recital data type then appended into a table. The table name is also passed as a parameter.
procedure replaceit append blank for i = 1 to numfields if type(field(i)) = "N" replace &(field(i)) with val(data[&i]) elseif type(field(i)) = "D" replace &(field(i)) with stod(data[&i]) elseif type(field(i)) = "T" replace &(field(i)) with ctot(data[&i]) elseif type(field(i)) = "L" replace &(field(i)) with iif(data[&i]="T",.T.,.F.) elseif type(field(i)) = "Y" replace &(field(i)) with val(data[&i]) else replace &(field(i)) with data[&i] endif next return procedure starthere parameters cTable, cFile numfields=xmlfirst(cFile,targ,trans,where,fldnames,data) if numfields < 1 dialog box [No records in XML file] else use &cTable replaceit() endif numrecs = xmlcount(cFile) if numrecs > 1 numleft = numrecs -1 for i = 1 to numleft xmlnext(trans,where,fldnames,data) replaceit() next endif return
Alternative Import/Export Methods
Other features exist in Recital to facilitate the import and export of data:
RDDs
The RDDs, Replaceable Database Drivers, are available on Windows, Linux and all supported 32-bit UNIX platforms. They allow for the use and creation of database tables and indexes in FoxPro, dBase and Clipper formats. The file format is the same across all the platforms that support the RDDs, allowing the tables and indexes to be transferred as required. The formats are also supported by a wide range of third-party products as well as their originating database systems. For more information on the RDDs, please see the online documentation on Xbase migration and the SET FILETYPE command.
BUILD/INSTALL
These are Recital/4GL commands for the export (BUILD) and import (INSTALL) of Recital tables and their associated memo, dictionary and multiple index files in ASCII format to allow them to be transferred across binary incompatible platforms. For more information, please see the online documentation on Recital/4GL commands.
COPY Commands
The COPY TO, COPY STRUCTURE, COPY STRUCTURE EXTENDED and CREATE FROM commands can all be used to enable data to be transferred between different formats and different platforms. For more information, please see the online documentation on Recital/4GL commands.
Appendix 1: Microsoft® ActiveX® Data Objects XML Format
For detailed information on the Microsoft® ActiveX® Data Objects XML Format, please consult the following Microsoft documentation:
Link |
Privacy Policy
We respect and are committed to protecting your privacy.
We require that you provide some personal information, to allow us to provide the services we do to the users of recitalsoftware.com, and to improve recitalsoftware.com. The type of information we collect, how we use it, and what choices you have, are detailed in this policy.
Information Collection and Use
We collect the information you provide when you register for an account or complete an information request form.
We use this information to satisfy your requests for further information, to customize our responses and our future communication with you, and to contact you, regarding development and events in the projects or areas of recitalsofware.com that you have expressed interest in, or in recitalsoftware.com, in general.
We make every effort to allow you to opt-in and opt-out of receiving messages from recitalsoftware.com. However, if you are receiving messages from us and cannot find a way to unsubscribe, please contact us at This email address is being protected from spambots. You need JavaScript enabled to view it..
Information Sharing
We will not release your personal information to anyone by any method, including selling, renting, or sharing, unless:
- you grant us permission
- we are required to do so by law
We will not share personal identification information data, either for single individuals or groups, with any parties, including those affiliated with recitalsoftware.com, such as members or sponsors.
How We Use Cookies
This website uses cookies. A cookie is a small amount of text data, sent from our webserver to your browser, and stored on your device. The cookie is sent back to the webserver each time the browser connects to this site. We use cookies to personalize the site and to streamline your interaction with the site.
It may be possible to configure your browser to refuse cookies, or to ask you to accept each time a cookie is offered. If you choose not to accept cookies, areas of this site may have reduced functionality or performance.
Software on our servers, or third party web statics services, may store your IP address, and other information passed on by your browser (such as browser version, operating system, screen size, language, etc). recitalsoftware.com and/or third party services will aggregate this information to provide usages statistics for this website. We use this information to optimize the design, structure, and performance of this site. In particular, we use Google Analytics to provide usage statistics. For more information, read the Google Analytics Privacy Policy.
Data Security
recitalsoftware.com is also committed to the security of your personal information. We train those who work on recitalsoftware.com on this privacy policy. On our site, we use SSL (Secure Sockets Layer) to protect your personal information, by encrypting your information when you send it to recitalsoftware.com.
Public Forum Content
recitalsoftware.com makes available to its users communication forums, such as mail lists, blogs, and others. Be aware that any information or messages you share in these forums becomes public information immediately. Exercise caution in determining whether to disclose any of your personal information. recitalsoftware.com reserves the right to act as necessary to preserve the integrity of the site and its forums, including removing any and all posts deemed vulgar or inappropriate.
Children's Online Privacy
Regarding children under the age of 13, recitalsoftware.com does not knowingly:
- accept personal information from them
- allow them to become registered members of our web site
Updates to this Privacy Policy
We may update this policy. We will contact you if we make any substantial changes in how we use your personal information.
This privacy policy was last updated on July 1, 2010.
Contact Information
If you have any questions about this privacy policy itself, or on how we use personal information on recitalsoftware.com, please contact us at This email address is being protected from spambots. You need JavaScript enabled to view it..
SET DATADIR TO [ <directory> ]This command is used to specify a directory where database tables, memos, indexes, and dictionary files are located. When a table is being opened this directory is searched first before the current directory and the file search path to locate the table and its associated files. This allows the database tables to be relocated to a different file system without the need to change an existing application.
In this article Chris Mavin, explains and details how to use the Recital Database Server with the Open Source Servlet Container Apache Tomcat.
Overview
PHP has exploded on the Internet, but its not the only way to create web applications and dynamic websites. Using Java Servlets, JavaServer Pages and Apache Tomcat you can develop web applications in a more powerful full featured Object Oriented Language, that is easier to debug, maintain, and improve.
Tomcat Installation
There are a number of popular Java application servers such as IBM Web Sphere and BEA WebLogic but today we will be talking about the use of Apache Tomcat 5, the Open Source implementation of the Java Servlet and JavaServer Pages technologies developed at the Apache Software Foundation. The Tomcat Servlet engine is the official reference implementation for both the Servlet and JSP specifications, which are developed by Sun under the Java Community Process. What this means is that the Tomcat Server implements the Servlet and JSP specifications as well or better than most commercial application servers.
Apache Tomcat is available for free but offers many of the same features that commercially available Web application containers boast.
Tomcat 5 supports the latest Servlet and JSP specifications, Servlet 2.4, and JSP 2.0, along with features such as:
-
Tomcat can run as a standalone webserver or a Servlet/JSP engine for other Web Servers.
-
Multiple connectors - for enabling multiple protocol handlers to access the same Servlet engine.
-
JNDI - The Java Naming and Domain Interface is supported.
-
Realms - Databases of usernames and passwords that identify valid users of a web application.
-
Virtual hosts - a single server can host applications for multiple domain names. You need to edit server.xml to configure virtual hosts.
-
Valve chains.
-
JDBC - Tomcat can be configured to use any JDBC driver.
-
DBCP - Tomcat can use the Apache commons DBCP for connection pooling.
-
Servlet reloading (Tomcat monitors any changes to the classes deployed within that web server.)
-
HTTP functionality - Tomcat functions as a fully featured Web Server.
-
JMX, JSP and Struts-based administration.
Tomcat Installation
In this next two sections we will walk through the install and setup of Tomcat for use with the Recital database server.
To download Tomcat visit the Apache Tomcat web site is at http://jakarta.apache.org/tomcat.
Follow the download links to the binary for the hardware and operating system you require.
For Tomcat to function fully you need a full Java Development Kit (JDK). If you intend to simply run pre compiled JavaServer pages you can do so using just the Java Runtime Environment(JRE).
The JDK 1.5 is the preferred Java install to work with Tomcat 5, although it is possible to run Tomcat 5 with JDK 1.4 but you will have to download and install the compat archive available from the Tomcat website.
For the purpose of this article we will be downloading and using Tomcat 5 for Linux and JDK 5.0,
you can download the JDK at http://java.sun.com/javase/downloads/index.jsp.
Now we have the JDK, if the JAVA_HOME environment variable isn't set we need to set it to refer to the base JDK install directory.
Linux/Unix:
$ JAVA_HOME= /usr/lib/j2se/1.4/ $ EXPORT $JAVA_HOME
Windows NT/2000/XP:
Follow the following steps:
1. Open Control Panel.
2. Click the System icon.
3. Go to the Advanced tab.
4. Click the Environment Variables button.
5. Add the JAVA_HOME variable into the system environment variables.
The directory structure of a Tomcat installation comprises of the following:
/bin - Contains startup, shutdown and other scripts. /common - Common classes that the container and web applications can use. /conf - Contains Tomcat XML configuration files XML files. /logs - Serlvet container and application logs. /server - Classes used only by the Container. /shared - Classes shared by all web application. /webapps - Directory containing the web applications. /work - Temporary directory for files and directories.
The important files that you should know about are the following:
-
server.xml
The Tomcat Server main configuration file is the [tomcat install path]\conf\server.xml file. This file is mostly setup correctly for general use. It is within this file where you specify the port you wish to be running the server on. Later in this article I show you how to change the default port used from 8080 to port 80.
-
web.xml
The web.xml file provides the configuration for your web applications. There are two locations where the web.xml file is used,
web-inf\web.xml provides individual web application configurations and [tomcat install path]conf\web.xml contains the server wide configuration.
Setting up Tomcat for use
We'll start by changing the port that Tomcat will be listening on to 80.
To do this we need to edit [tomcat install path]/conf/server.xml and change the port attribute of the connector element from 8080 to 80.
After you have made the alteration the entry should read as:
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 --> <Connector port="80" maxHttpHeaderSize="8192"
Next we want to turn on Servlet reloading, this will cause the web application to be recompiled each time it is accessed, allowing us to make changes to the files without having to worry about if the page is being recompiled or not.
To enable this you need to edit [tomcat install path]/conf/context.xml and change <Context> element to <Context reloadable="true">.
After you have made the alteration the entry should read as:
<Context reloadable="true"> <WatchedResource>WEB-INF/web.xml</WatchedResource> </Context>
Next we want to enable the invoker Servlet.
The "invoker" Servlet executes anonymous Servlet classes that have not been defined in a web.xml file. Traditionally, this Servlet is mapped to the URL pattern "/servlet/*", but you can map it to other patterns as well. The extra path info portion of such a request must be the fully qualified class name of a Java class that implements Servlet, or the Servlet name of an existing Servlet definition.
To enable the invoker Servlet you need to edit the to [tomcat install path]/conf/web.xml and uncomment the Servlet and Servlet-mapping elements that map the invoker /servlet/*.
After you have made the alteration the entry should read as:
<servlet> <servlet-name>invoker</servlet-name> <servlet-class>org.apache.catalina.servlets.InvokerServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <load-on-startup>2</load-on-startup> </servlet> <servlet-mapping> <servlet-name>invoker</servlet-name> <url-pattern>/servlet/*</url-pattern> </servlet-mapping>
If you are you not interested in setting up your own install of Tomcat there are prebuilt versions Tomcat that has all of the above changes already made, and has the test HTML, JSP, and Servlet files already bundled. Just unzip the file, set your JAVA_HOME
Next we will give Tomcat and your web applications access to the Recital JDBC driver.
For the purposes of this article we are going to install the Recital JDBC driver in the /[tomcat install path]/common/lib/ this gives Tomcat and your web applications access to the Recital JDBC driver. The driver can be installed in a number of places in the Tomcat tree, giving access to the driver to specific application or just to the web application and not the container. For more information refer to the Tomcat documentation.
Copy the recitalJDBC.jar which is located at /[recital install path]/drivers/recitalJDBC.jar to the /[tomcat install path]/common/lib/ directory.
Linux:
$cp /[recital install path]/drivers/recitalJDBC.jar /[tomcat install path]/common/lib/
Once you have completed all the steps detailed above, fire up the server using the script used by your platform's Tomcat installation.
Linux/Unix:
[tomcat install path]/bin/startup.sh
Windows:
[tomcat install path]/bin/startup
If you are having problems configuring your Tomcat Installation or would like more detail visit the online documentation a the Apache Tomcat site.
Example and Links
Now we have setup our Tomcat installation, lets get down to it with a JSP example which uses the Recital JDBC driver to access the demonstration database (southwind) shipped with the Recital Database Server.
The example provided below is a basic JDBC web application, where the user simply selects a supplier from the listbox and requests the products supplied by that supplier.
To run the example download and extract the tar archive or simple save each of the two jsp pages individually into /[tomcat install path]/webapps/ROOT/ on your server.
By enabling the invoker Servlet earlier we have removed the need to set the example up as a web application in the Tomcat configuration files.
You can now access the example web application at http://[Server Name]/supplier.jsp if the page doesn't display, check you have followed all the Tomcat installation steps detailed earlier in this article and then make sure both Tomcat and a licensed Recital UAS are running.
Downloads:
Archive: jspExample.tar
Right click and save as individual files and rename as .jsp files:
supplier.txt details.txt
Further Reading on JSP and JDBC can be found at http://www-128.ibm.com/developerworks/java/library/j-webdata/
Final Thoughts
Recital and Apache tomcat are a powerful combination, using Java Servlet technology you can separate application logic and the presentation extremely well. Tomcat, JSP, Java Servlets and the Recital database server form a robust platform independent, easily maintained and administered solution with which to unlock the power of your Recital, Foxpro, Foxbase, Clipper, RMS and C-SAM data.
This article discusses Recital database security: from operating system file permissions through file and field protection to DES3 encryption.
Overview
A company's data is extremely valuable and must be protected, both in operation and in physical file format. Recital products provide a range of ways to protect your data.
Operating System File Permissions
The most basic level of database security is provided by the operating system. Recital database tables and indexes are individual files with their own respective operating system file permissions. Read permission is required to open a table and write permission to update a table. If a user does not have read permission they are denied access. Without write permission, a table will be opened read-only.
Here the owner, root, and members of the recital group have write permission, so can update the example table unless additional protection applies. Other users can only open the example table read-only.
# ls -l example* -rwxrwxr-x 1 root recital 147 Nov 29 14:27 example.dbd -rwxrwxr-x 1 root recital 41580 Nov 29 14:27 example.dbf -rwxrwxr-x 1 root recital 13312 Nov 29 14:28 example.dbt -rwxrwxr-x 1 root recital 19456 Nov 29 14:28 example.dbx
Note: As in the example above, a table's associated files should have the same permissions as the table itself:
File Extension |
File Type |
.dbd |
Dictionary |
.dbf |
Table |
.dbt |
Memo |
.dbx |
Index |
Database Dictionary
Each Recital table may have a Database Dictionary. The Dictionary can be used both to protect the integrity of the data and to protect access to the data. This section covers Column Constraints, Triggers, Security and Protection.
Column Constraints: Data Integrity
The Dictionary attributes or constraints either prevent the entry of incorrect data, e.g. must_enter and validation or aid the entry of correct data, e.g. default, picture and choicelist. The Dictionary can be modified in the character mode CREATE/MODIFY STRUCTURE worksurface, via SQL statements, or in the Recital Enterprise Studio Database Administrator.
Click image to display full size
Fig 1: MODIFY STRUCTURE Worksurface: Dictionary.
The SQL Column Constraints are as follows:
Constraint |
Description |
AUTO_INCREMENT | AUTOINC |
Used to auto increment the value of a column. |
CALCULATED |
Used to calculate the value of a column. |
CHECK | SET CHECK |
Used to validate a change to the value of a column. |
DEFAULT |
Used to set a default value for the specified column. |
DESCRIPTION |
Used set the column description for the specified column. |
ERROR |
Used to define an error message to be displayed when a validation check fails. |
FOREIGN KEY |
Used to define a column as a Foreign Key for a parent table. |
NOCPTRANS |
Used to prevent code page translation for character and memo fields. |
NOT NULL | NULL |
Used to disallow/allow NULL values. |
PRIMARY KEY |
Used to define a tables Primary Key. |
RANGE |
Used to specify minimum and maximum values for a date or numerical column. |
RECALCULATE |
Used to force recalculation of calculated columns when a columns value changes. |
REFERENCES |
Used to create a relationship to an index key of another table. |
UNIQUE |
Used to define the column as a candidate index for the table |
These can be specified in CREATE TABLE or ALTER TABLE statements:
exec sql OPEN DATABASE southwind; exec sql ALTER TABLE customers ADD COLUMN timeref char(8) CHECK validtime(timeref) ERROR "Not a valid time string";
Click image to display full size
Fig 2: Database Administrator: Column Constraints and Attributes.
TRIGGERS
Table Level Triggers are event-driven procedures called before an I/O operation. These can be used to introduce another layer of checks before a particular operation is permitted to take place or to simply set up logging of those operations.
The CREATE/MODIFY STRUCTURE worksurface <TRIGGERS> menu bar option allows you to specify table level triggers. You may edit a trigger procedure from within the <TRIGGERS> menu by placing the cursor next to the procedure name and pressing the [HELP] key. A text window pops up for editing. If the table triggers are stored in separate <.prg> files, rather than in a procedure library, procedures need not be predefined (SET PROCEDURE) before using the table.
Click image to display full size
Fig 3: MODIFY STRUCTURE Worksurface: Triggers.
The following triggers can be selected and associated with a specified procedure name in the <TRIGGERS> menu.
Trigger |
Description |
UPDATE |
The specified procedure is called prior to an update operation on the table. If the procedure returns .F., then the UPDATE is canceled. |
DELETE |
The specified procedure is called prior to a delete operation on the table. If the procedure returns .F., then the DELETE is canceled. |
APPEND |
The specified procedure is called prior to an append operation on the table. If the procedure returns .F., then the APPEND is canceled. |
OPEN |
The specified procedure is called after an open operation on the table. |
CLOSE |
The specified procedure is called prior to a close operation on the table. |
ROLLBACK |
The specified procedure is called when a user presses the [ABANDON] key in a forms based operation. |
The Recital Enterprise Studio Database Administrator also allows you to associate existing programs as Table Trigger Procedures.
Click image to display full size
Fig 4: Database Administrator: Triggers.
Programmatically, Trigger Procedures can also be associated with a table using SQL. The following table constraints may be applied in the SQL CREATE TABLE and ALTER TABLE statements:
Trigger |
Description |
ONUPDATE |
The specified procedure is called prior to an update operation
on the table. If the procedure returns .F., then the UPDATE
is canceled. |
ONDELETE |
The specified procedure is called prior to a delete operation
on the table. If the procedure returns .F., then the DELETE
is canceled. |
ONINSERT |
The specified procedure is called prior to an insert operation
on the table. If the procedure returns .F., then the INSERT
is canceled. |
ONOPEN |
The specified procedure is called after an open operation
on the table. |
ONCLOSE |
The specified procedure is called prior to a close operation
on the table. |
ONROLLBACK |
The specified procedure is called when a user presses the
[ABANDON] key in a forms based operation. |
SECURITY
As mentioned above, all Recital files are subject to Operating System read and write permissions. These permissions can be further refined, while still using the Operating System user and group IDs, in the Security and Protection sections of the Dictionary. The Security section handles table based operations and the Protection section focuses on individual fields.
Security and Protection rules can be defined in the CREATE/MODIFY STRUCTURE worksurface of Recital Terminal Developer, via the SQL GRANT and REVOKE statements or in the Recital Enterprise Studio Database Administrator.
Click image to display full size
Fig 5: MODIFY STRUCTURE Worksurface: Security.
The Security section has table operations for which Access Control Strings can be specified. An Access Control String (ACS) is a range of valid user identification codes, and is used to restrict table operations to certain individuals or groups. Each user on the system is allocated a group number and a user number. The user identification code is the combination of group and user numbers. When constructing an Access Control String of linked user identification codes, wild card characters may be used.
Example ACS |
Description |
[1,2] |
In group 1, user 2 |
[100,*] |
In group 100, all users |
[2-7,*] |
In groups 2-7, all users |
[*,100-200] |
In all groups, users 100-200 |
[1,*]&[2-7,1-7] |
In group 1, all users, in groups 2-7, users 1-7 |
Please note that the maximum ACS length is 254 characters. OpenVMS group and user numbers are stored and specified in octal. On other Operating Systems, group and user numbers are stored and specified in decimal.
Access Control Strings may be associated with the following operations:
Operation |
Description |
READONLY |
Users specified in the ACS have read-only access to the table. All other users have update access. |
UPDATE |
Users specified in the ACS have update access to the table. All other users are restricted to read-only access. |
APPEND |
Users specified in the ACS can append records into the table. No other users can append. |
DELETE |
Users specified in the ACS can delete records from the table. No other users can delete. |
COPY |
Users specified in the ACS can copy records from the table. No other users can copy. |
ADMIN |
Users specified in the ACS can use the following commands: |
The corresponding SQL privileges are:
Operation |
Description |
SELECT |
Users specified in the ACS may name any column in a SELECT statement. All other users have update access. |
UPDATE |
Users specified in the ACS may name any column in an UPDATE statement. All other users are restricted to read-only access. |
INSERT |
Users specified in the ACS can INSERT rows into the table. No other users can INSERT. |
DELETE |
Users specified in the ACS can DELETE rows from the table. No other users can DELETE. |
ALTER |
Users specified in the ACS can use the ALTER TABLE statement on this table. |
READONLY |
Users specified in the ACS may read any column in a SELECT statement. All other users have update access. |
// Grant insert privilege for the customer table exec sql OPEN DATABASE southwind; exec sql GRANT UPDATE (lastname, firstname) INSERT ON customers TO '[20,100]'; // Grant all privileges to all users exec sql OPEN DATABASE southwind; exec sql GRANT ALL ON shippers TO PUBLIC;
PROTECTION
Security and Protection rules can be defined in the CREATE/MODIFY STRUCTURE worksurface of Recital Terminal Developer, via the SQL GRANT and REVOKE statements or in the Recital Enterprise Studio Database Administrator.
Click image to display full size
Fig 6: Database Administrator: Protection.
The format of the ACS is the same as in <SECURITY> above.
The following protection can be defined:
Operation |
Description |
READONLY |
Users specified in the ACS have read-only access to the field. All other users have update access. |
UPDATE |
Users specified in the ACS have update access to the field. All other users are restricted to read-only access. |
Recital Terminal Developer also has 'HIDDEN' Protection:
Operation |
Description |
HIDDEN |
Users specified in the ACS see the 'hiddenfield'character rather than the data in the field. All other users see the data. |
Hidden fields can be accessed and viewed on a work surface, but the field contains the hiddenfield character, ?. If the field is referenced in an expression, it will contain the following: blanks for character fields, F for logical fields, 00/00/0000 for date fields and blank for memo fields.
The corresponding SQL privileges are:
Operation |
Description |
SELECT |
Users specified in the ACS may name the column in a SELECT statement. All other users have update access. |
UPDATE |
Users specified in the ACS may name the column in an UPDATE statement. All other users are restricted to read-only access. |
READONLY |
Users specified in the ACS may read the column in a SELECT statement. All other users have update access. |
// Grant update privilege for columns lastname and firstname from the customer table exec sql OPEN DATABASE southwind; exec sql GRANT UPDATE (lastname, firstname) customers TO '[20,100]';
Encryption
From Recital 8.5 onwards, Recital installations that have the additional DES3 license option have the ability to encrypt the data held in Recital database tables. Once a database table has been encrypted, the data cannot be accessed unless the correct three-part encryption key is specified, providing additional security for sensitive data.
ENCRYPT
The ENCRYPT Recital 4GL command is used to encrypt the data in the specified table or tables matching a skeleton. If the skeleton syntax is used, then all matching tables will be given the same encryption key. The encryption key is a three part comma-separated key and may optionally be enclosed in angled brackets. Each part of the key can be a maximum of 8 characters. The key is DES3 encrypted and stored in a .dkf file with the same basename as the table. After encryption, the three parts of the key must be specified correctly before the table can be accessed.
// Encrypt individual tables encrypt customers key "key_1,key_2,key_3" encrypt employees key "<key_1,key_2,key_3>" // Encrypt all .dbf files in the directory encrypt *.dbf key "key_1,key_2,key_3"
SET ENCRYPTION
If a database table is encrypted, the correct three-part encryption key must be specified before the table's data or structure can be accessed. The SET ENCRYPTION TO set command can be used to specify a default encryption key to be used whenever an encrypted table is accessed without the key being specified. The encryption key is a three part comma-separated key.
If the command to access the table includes the key, either by appending it to the table filename specification or using an explicit clause, this will take precedence over the key defined by SET ENCRYPTION TO.
Issuing SET ENCRYPTION TO without a key causes any previous setting to be cleared. The key must then be specified for each individual encrypted table.
The default key defined by SET ENCRYPTION is only active when SET ENCRYPTION is ON. SET ENCRYPTION OFF can be used to temporarily disable the default key. The SET ENCRYPTION ON | OFF setting does not change the default key itself. SET ENCRYPTION is ON by default.
// Encrypt individual tables encrypt customers key "key_1,key_2,key_3" encrypt shippers key "key_2,key_3,key_4" // Specify a default encryption key set encryption to "key_1,key_2,key_3" // Open customers table using the default encryption key use customers // Specify shippers table's encryption key use shippers<key_2,key_3,key_4> // Disable the default encryption key set encryption to // Specify the individual encryption keys use customers encryption "key_1,key_2,key_3" use shippers<key_2,key_3,key_4>
DECRYPT
The DECRYPT command is used to decrypt the data in the specified table or tables matching a skeleton. The specified key must contain the three part comma-separated key used to previously encrypt the table and may optionally be enclosed in angled brackets. The skeleton syntax can only be used if all tables matching the skeletonhave the same key.
The DECRYPT command decrypts the data and removes the table’s .dkf file. After decryption, the key need no longer be specified to gain access to the table.
// Decrypt individual tables decrypt customers key "key_1,key_2,key_3" decrypt employees key "<key_1,key_2,key_3>" // Decrypt all .dbf files in the directory decrypt *.dbf key "key_1,key_2,key_3"
All of the following commands are affected when a table is encrypted:
- APPEND FROM
- COPY FILE
- COPY STRUCTURE
- COPY TO
- DIR
- USE
- SQL INSERT
- SQL SELECT
- SQL UPDATE
APPEND FROM
Used to append records to the active table from another table.// The key must be specified for an encrypted source table
use mycustomers append from customers encryption "key_1,key_2,key_3"; for country = "UK"
COPY FILE
Used to copy a file.// The key file must also be copied for an encrypted source table // as the target table will be encrypted
encrypt customers key "key_1,key_2,key_3" copy file customers.dbf to newcustomers.dbf copy file customers.dkf to newcustomers.dkf use newcustomers encryption "key_1,key_2,key_3"
COPY STRUCTURE
Used to copy a table's structure to a new table.// The key file is automatically copied for an encrypted source table // and the target table encrypted
encrypt customers key "key_1,key_2,key_3"
use customers encryption "key_1,key_2,key_3" copy structure to blankcust use blankcust encryption "key_1,key_2,key_3"
COPY TO
Used to copy a table.// By default, the key file is automatically copied for an encrypted // source table and the target table encrypted with the same key encrypt customers key "key_1,key_2,key_3" use customers encryption "key_1,key_2,key_3" copy to newcustomers use newcustomers encryption "key_1,key_2,key_3" // You can also create a copy with a different key encrypt customers key "key_1,key_2,key_3" use customers encryption "key_1,key_2,key_3" copy to newcustomers encrypt "newkey_1,newkey_2,newkey_3" use newcustomers encryption "newkey_1,newkey_2,newkey_3" // Or create a decrypted copy encrypt customers key "key_1,key_2,key_3" use customers encryption "key_1,key_2,key_3" copy to newcustomers decrypt use newcustomers // You can also create an encrypted copy of a non-encrypted source table use orders copy to encorders encrypt "newkey_1,newkey_2,newkey_3" use encorders encryption "newkey_1,newkey_2,newkey_3"
DIR
Used to display a directory listing of tables.// Encrypted tables are flagged as such with (DES3) > open database southwind > dir
Current database: southwind Tables # Records Last Update Size Dictionary Triggers Security categories.dbf 8 01/10/06 24576 None None None cisamdemo.dbf ---> CISAM/Bridge [cisamdemo] customers.dbf (DES3) 91 05/12/04 49600 None None None employees.dbf 9 05/12/04 25520 None None None example.dbf (DES3) 100 12/24/05 38080 Yes Yes None order_details.dbf 2155 05/12/04 296320 None None None orders.dbf 829 05/12/04 232704 None None None products.dbf 77 05/12/04 37112 None None None productsbyname.dbf 77 05/12/04 29104 None None None shippers.dbf (DES3) 3 05/12/04 20864 None None None suppliers.dbf 29 12/08/05 29992 Yes None None 0.765 MB in 11 files. 1.093 GB remaining on drive.
USE
Used to open a table.// The three part key must be specified to open an // encrypted table. All of the following are valid. // 1. Specifying a default encryption key before opening the table set encryption to "key_1,key_2,key_3" use customers // 2. Appending the key to the filename use customers<key_1,key_2,key_3> // 3. Using the ENCRYPTION clause, optionally specifying angled brackets use customers encryption "key_1,key_2,key_3" use customers encryption "<key_1,key_2,key_3>"
SQL INSERT
Used to add a row to a table via SQL.// The three part key can be specified using a // default encryption key before opening the table exec sql OPEN DATABASE southwind; exec sql SET ENCRYPTION TO "key_1,key_2,key_3"; exec sql INSERT INTO customers (customerid, companyname) VALUES ('RECIT','Recital Corporation'); // Or by appending the key to the filename exec sql OPEN DATABASE southwind; exec sql INSERT INTO customers<key_1,key_2,key_3> (customerid, companyname) VALUES ('RECIT','Recital Corporation');
SQL SELECT
Used to return data from a table via SQL.// The three part key can be specified using a // default encryption key before opening the table exec sql OPEN DATABASE southwind; exec sql SET ENCRYPTION TO "key_1,key_2,key_3"; exec sql SELECT * FROM customers; // Or by appending the key to the filename exec sql OPEN DATABASE southwind; exec sql SELECT * FROM customers<key_1,key_2,key_3>;
SQL UPDATE
Used to update data in a table via SQL.// The three part key can be specified using a // default encryption key before opening the table exec sql OPEN DATABASE southwind; exec sql SET ENCRYPTION TO "key_1,key_2,key_3"; exec sql UPDATE customers SET companyname='Recital Corporation Inc.' WHERE customerid='RECIT'; // Or by appending the key to the filename exec sql OPEN DATABASE southwind; exec sql UPDATE customers<key_1,key_2,key_3> SET companyname='Recital Corporation Inc.' WHERE customerid='RECIT';
Summary
Recital offers a range of ways to keep your data secure. These start with the Operating System read/write permissions, which can be further refined to the level of table I/O operations and then field access in the Dictionary based Security and Protection rules. The Dictionary also provides the means to protect the integrity of the data via data validation and to assist in correct data entry through the use of choicelists, help messages and picture clauses etc. A further role of the Dictionary is in the provision of Table Triggers, which can be used to enable a programmatic response to table operations to add in additional checks or audit trails. For the most sensitive data, DES3 encryption is the ultimate protection: encrypting the physical data on the disk and only permitting table access on the production of the three part encryption key.
Another useful article on IBM developerworks shows how to build PHP extensions using SWIG. You can find the article here.
Unfortunately java does not support __FILE__ and __LINE__ but you can get the same functionality with this code which can be placed in one of your libraries.
public static void showTrace(String msg) { if (msg.length() > 0) System.out.println(msg); System.out.println("Trace: " + "file " + new Throwable().getStackTrace()[1].getFileName() + " class " + new Throwable().getStackTrace()[1].getClassName() + " method " + new Throwable().getStackTrace()[1].getMethodName() + " line " + new Throwable().getStackTrace()[1].getLineNumber()); }
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!