In this article Barry Mavin, CEO and Chief Software Architect for Recital, details Working with Stored Procedures in the Recital Database Server.

Overview

Stored procedures and user-defined functions are collections of SQL statements and optional control-of-flow statements written in the Recital 4GL (compatible with VFP) stored under a name and saved in a Database. Both stored procedures and user-defined functions are just-in-time compiled by the Recital database engine. Using the Database Administrator in Recital Enterprise Studio, you can easily create, view, modify, and test Stored Procedures, Triggers, and user-defined functions

Creating and Editing Stored Procedures

To create a new Stored Procedure,  right-click the Procedures node in the Databases tree of the Project Explorer and choose Create. To modify an existing stored procedure select the Stored Procedure in the Databases Tree in the Project Explorer by double-clicking on it or selecting 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.

Testing the Procedure

To test run the Stored Procedure, select the Stored Procedure 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 procedure.

Getting return values

Example Stored Procedure called "sp_myproc":

parameter arg1, arg2
return arg1 + arg2

Example calling the Stored Procedure from C# .NET:

////////////////////////////////////////////////////////////////////////
// include the references below
using System.Data;
using Recital.Data;

////////////////////////////////////////////////////////////////////////
// sample code to call a Stored Procedure that adds to numeric values together
public int CallStoredProcedure()
{
	RecitalConnection conn = new 
		RecitalConnection("Data Source=localhost;Database=southwind;uid=?;pwd=?");
	RecitalCommand cmd = new RecitalCommand();
	cmd.Connection = conn;
	cmd.CommandText = "sp_myproc(@arg1, @arg2)";
	cmd.CommandType = CommandType.StoredProcedure;
	cmd.Parameters["@arg1"].Value = 10;
	cmd.Parameters["@arg2"].Value = 20;
	conn.Open();
	cmd.ExecuteNonQuery();
	int result = (int)(cmd.Parameters["retvalue"].Value);    // get the return value from the sp
	conn.Close();
	return result;
	}

Writing Stored Procedures that return a Resultset

If you want to write a Stored Procedure that returns a ResultSet, you use the SETRESULTSET() function of the 4GL. Using the Universal .NET Data Provider, you can then execute the 4GL Stored Procedure and return the ResultSet to the client application for processing. ResultSets that are returned from Stored Procedures are read-only.

Example Stored Procedure called "sp_myproc":

parameter query
select * from customers &query into cursor "mydata"
return setresultset("mydata")

Example calling the Stored Procedure from C# .NET:

////////////////////////////////////////////////////////////////////////
// include the references below
using System.Data;
using Recital.Data;

////////////////////////////////////////////////////////////////////////
// sample code to call a stored procedure that returns a ResultSet
public void CallStoredProcedure()
{
	RecitalConnection conn = new 
		RecitalConnection("Data Source=localhost;Database=southwind;uid=?;pwd=?");
	RecitalCommand cmd = new RecitalCommand();
	cmd.Connection = conn;
	cmd.CommandText = "sp_myproc(@query)";
	cmd.CommandType = CommandType.StoredProcedure;
	cmd.Parameters["@query"].Value = "where not deleted()";
	conn.Open();
	RecitalDataReader dreader = cmd.ExecuteReader();
	int sqlcnt = (int)(cmd.Parameters["sqlcnt"].Value);    // returns number of affected rows
	while (dreader.Read())
	{
		// read and process the data
	}
	dreader.Close();
	conn.Close();
}

Recital is a dynamic programming language with an embedded high performance database engine particularly well suited for the development and deployment of high transaction throughput applications.

The Recital database engine is not a standalone process with which the application program communicates. Instead, the Recital database is an integral part of any applications developed in Recital. 

Recital implements 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.

The Recital database engine, although operating as an embedded database in the user process, multiple users and other background processes may access the same data concurrently. Read accesses are satisfied in parallel. Recital uses automatic record level locking when performing database updates. This provides for a high degree of database concurrency and superior application performance and differentiates the Recital database from other embeddable databases such as sqlite that locks the entire database file during writing. 

Key features of the Recital scripting language include:

• High performance database application scripting language
• Modern object-oriented language features
• Easy to learn, easy to use
• Fast, just-in-time compiled
• Loosely-typed
• Garbage collected
• Static arrays, Associative arrays and objects
• Develop desktop or web applications
• Cross-platform support
• Extensive built-in functions
• Superb built-in SQL command integration
• Navigational data access for the most demanding applications
• Scripting  language is upward compatible with FoxPRO

Key features of the Recital database include:

• A broad subset of ANSI SQL 99, as well as extensions
• Cross-platform support
• Stored procedures
• Triggers
• Cursors
• Updatable Views
• System Tables
• Query caching
• Sub-SELECTs (i.e. nested SELECTs)
• Embedded database library
• Fault tolerant clustering support
• Chronological data versioning with database timelines
• Optional DES3 encrypted data
• Hot backup
• Client drivers for ODBC, JDBC and .NET 

It would appear that gigabit LAN is not! In fact it often runs at the same speed as 100Mbps LAN. Let's look at why exactly.

After configuring your network you can use the ifconfig command to see what speeds the LAN is connected. Even though 1000Mbps is reported by the card, the reality is that the overall throughtput may well be ~100Mpbs. You can try copying a large file using scp to demonstrate this.

As it turns out, in order to use a gigabit LAN you need to use CAT6 cables. CAT5 and CAT5E are not good enough. End result, the ethernet cards throttle back the speed to reduce dropped packets and errors.

You can find a good article here titled Squeeze Your Gigabit NIC for Top Performance. After tuning up the TCP parameters i found that it made no dfifference. The principal reasons behind low gigabit ethernet performance can be summed up as follows.

1. Need to use CAT6 cables
2. Slow Disk speed
3. Limitations of the PCI bus which the gigabit ethernet cards use

You can get an idea about the disk speed using the hdparm command:

Display the disk partitions and choose the main linux partition which has the / filesystem.

# fdisk -l

Then get disk cache and disk read statistics:

# hdparm -Tt /dev/sda0

On my desktop system the sata disk perfomance is a limiting factor. These were the results:

/dev/sda1:
Timing cached reads:   9984 MB in  2.00 seconds = 4996.41 MB/sec
Timing buffered disk reads:   84 MB in  3.13 seconds =  58.49 MB/sec

Well, that equates to a raw disk read speed of 58.49 * 8 = 467Mbps which is half the speed of a gigabit LAN.

So.. NAS storage with lots of memory looks to be the way to go... If you use the right cables!