Application Development in Firebird - Firebird

Once you create and populate a database, its content can be accessed through a client application. Some client applications—such as the Firebird isql tool and a range of excellent commercial and open source database administration tools—provide the capability to query data interactively and to create new metadata.

Any application developed as a user interface to one or more Firebird databases will use the SQL query language, both to define the sets of data that can be stored and to pass SQL statements to the server requesting operations on data and metadata.

Firebird implements a set of SQL syntaxes that have a high degree of compliance with the recognized SQL-92 standards. The Firebird API provides complete structures for packaging SQL statements and the associated parameters, and for receiving the results back into applications.

Dynamic Client/Server Applications

Applications often need to cater for runtime SQL statements that are created and modified by applications, or entered by users on an ad hoc basis. Applications typically provide user selection lists, retrieved from database tables, from which users choose search criteria for the data they wish to retrieve and the operations they wish to perform. The program constructs queries from the users’ choices and manages the data retrieved.

Client applications use dynamic SQL (DSQL) for submitting queries in runtime. The Firebird client exposes the API as a library of functions that pass the complex record structures that form the data-level protocol for communication between the application and the server.

The Firebird Core API

Programming directly with the API is necessary when writing drivers for scripting languages such as PHP and Python and for developing object-oriented data access classes for object-oriented languages like Java, C++, and ObjectPascal. Applications may also be written to call the API functions directly, without the mediation of a driver. These “direct -to-API” applications can be powerful and flexible, with benefits in execution speed, small footprint, and fine control over memory allocation.

Core API Function Categories

API functions, all having names starting with isc_, fall into eight categories:

  • Database attach and detach (e.g., isc_attach_database())
  • Transaction start, prepare, commit, and rollback (e.g., isc_start_transaction())
  • Statement execution calls (e.g., isc_dsql_describe())
  • BLOB calls (e.g., isc_blob_info())
  • Array calls (e.g., isc_array_get_slice())
  • Database security (e.g., isc_attach_database())
  • Information calls (e.g., isc_database_info())
  • Date and integer conversions (e.g., isc_encode_date())

Application Interfaces Using the API

Applications that use drivers for generic interfaces like ODBC or JDBC rely on DSQL statements beneath user interfaces such as query builders and other tools.

With the rise of rapid application development (RAD) tools in the past decade, the encapsulation of the API functions in suites of classes and components presents a variety of attractive application development options for Firebird developers.

Object-Oriented Classes

Object-oriented data access classes and components encapsulate the function calls and structures of the API. All have properties and methods that analyze and parse request statements and manage the results passed back. The richer classes include methods and properties that support Firebird’s special capabilities, such as multidatabase transactions, array handling, and parameterized statements. Most component suites implement at least one class of container component for buffering one or more rows returned to the client as a result set. Some implement advanced techniques such as scrolling cursors, “live datasets,” callbacks, and transaction management.

The JayBird Type 4 (“native”) JDBC driver provides a dedicated interface for platform-independent development with Firebird in Java. Several component suites have become established as the interface of choice for developers using Delphi, Kylix, and C++Builder to write front-ends for Firebird databases. The two best-developed are IB Objects and FIBPlus. Several other component suites are available with lighter support for Firebird features.

Embedded Firebird Applications

Firebird provides for two distinct embedding models: embedded SQL applications and embedded servers.

Embedded SQL Applications

In this model, the application program incorporates both the client/server interface and the end-user application layers in a single executable. SQL statements are entered directly in the source code of a program written in C, C++, or another programming language. The application source code is then passed through gpre, the pre-processor, which searches the code for blocks of SQL statements. It substitutes them with source code macro function calls that are functionally equivalent to the dynamic API library functions. When this pre-processed source code is compiled, all of the plumbing for the SQL conversations is compiled directly into the application. These pre-compiled statements are known as static SQL.

A special, extra subset of SQL-like source commands is available for this style of application. Known as Embedded SQL (ESQL), it provides a simpler, high-level language “black box” for the programmer, while gpre does the grunt work of packaging the more complex language structures of the equivalent API calls. These pre-compiled statements give a slight speed advantage over dynamic SQL, because they avoid the overhead of parsing and interpreting the SQL syntax at runtime.

Embedded Server Applications

In the embedded server model, there is no pre-compilation of SQL conversations. The client and the server are merged into one compact dynamic library for deployment with a stand-alone application. The application loads the library when it starts up, just as a regular Firebird application would load the client library, and the API functions are called directly at runtime. However, no external server need be installed because this client communicates internally with its own instance of a Firebird server process. When the application terminates, it unloads the embedded server along with the client and no server process remains.

Although it does not use or emulate a network connection, the merged client/ server accesses the database in the same way as any other dynamic Firebird client application does. Existing application code written for use on a normal client server network works unmodified with the embedded server.

Embedded Server on Windows

The embedded server library fbembed.dll, included in the installer for Firebird 1.5 for Windows, is a variant of Firebird Superserver. If you plan to install it and give it a try, take care to read the special instructions for placement of Firebird’s libraries and executables. Updated README files and other notes are usually located in the \doc directory of a regular server installation.

You can install and run embedded server applications on a Windows machine that is also hosting a Firebird Superserver or Classic server, although remote clients cannot attach to a database while it is being accessed by an embedded server application. At release 1.5, when the deprecated IPSERVER protocol was still in use for the client/server communication, it was possible to use the embedded server library as a client to other host servers. In later versions, where the XNET communication protocol replaces IPSERVER, it is not possible.

Firebird 1.0.x does not have an embedded server option on Windows.

Embedded Server on Linux/UNIX

Embedded server is the “native” mode of access for a local client to the Firebird Classic server on Linux/UNIX, including Firebird 1.0.x. The embedded server library for local access is libfbembed.so in Firebird 1.5 and higher, and libgds.so in Firebird 1.0. x.

Like the Windows IPSERVER version, the Linux/UNIX embedded client can do double duty as a remote client to another Firebird Classic server. However, this client is not certain to be thread-safe. For mult-ithreaded applications it should be avoided in favor of the thread-capable remote client, libfbclient.so. In Firebird 1.0.x, the full remote client is distributed in the Linux Superserver kit and is confusingly named libgds.so, like the embedded Classic client.

The Services API

The opened InterBase 6.0 code—from which Firebird was developed—surfaced for the first time as an API providing a function call interface to certain server activities such as backup/restore, statistics, and user management. Many of these calls provide programming interfaces to the code in the command-line tools. A few lower-level server functions are included as well, some of which overlap functions already available in the core API.

Several shops have developed and distributed service components, encapsulating access to the Services API function calls from Delphi, Kylix, and C++Builder development environments. Most are free to download from authors’ or Firebird community websites.

In Firebird 1.0.x, the Services API and service components work only with Superserver servers. In Firebird 1.5, some functions—those that call the gbak (backup/ restore) and gfix (database housekeeping) modules—work with Classic server on Linux as well.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Firebird Topics