www.ibpp.org reference

reference:array

Tue, 23 Jan 2007 17:03:17 +0200

Firebird and Interbase do support the storage of arrays of values in a single column of a single row. This feature is not widely available at the Dynamic SQL interface level, and best require some C-API programming to be used. IBPP allows you to read and write those array columns easily.

reference:blob

Tue, 23 Jan 2007 17:01:59 +0200

Firebird and Interbase do support the storage of arbitrary binary data in a single column, the type of such a column is BLOB. This feature is not widely available at the Dynamic SQL interface level (except some simple text BLOBs extractions), and best require some C-API programming to be used. IBPP allows you to read and write those blob columns easily through a file I/O analogy.

reference:clientlibsearchpaths

Mon, 17 Apr 2006 20:45:46 +0200

This function is currently only implemented in Windows builds of IBPP. It is a no-op on other platforms. It allows the host application to better control which instance of fbclient.dll will get loaded and used by IBPP if there exists the possibility of multiple copies of fbclient.dll on the machine.

reference:compilers

Thu, 30 Mar 2006 18:07:01 +0200

This is a short documentation instructing you how to integrate IBPP source code in your own projects. It is basically the same information as what is available in the 'howtobuild.txt' file. Starting with version 2.5 IBPP does not provide anymore a stand-alone build procedure. IBPP is a set of C++ classes. A small hand of .h and .cpp files implement them. You might wish to compile them separately in a lib, then use the lib in your own programs, but it is as well easy, if not easier and safer, t…

reference:conversions

Thu, 30 Mar 2006 18:12:53 +0200

The bulk of programming with IBPP to interact with a Firebird database is to exchange values with the database, reading columns values and inserting or updating columns values. SQL has a number of basic types and C++ has its own set of primitive types. This article discusses relationships between both worlds, in the context of IBPP.

reference:database

Mon, 03 Apr 2006 12:17:05 +0200

The IBPP::Database Interface represents a single connection to a database. Along with IBPP::Transaction and IBPP::Statement, it is the core of IBPP. You need at least one instance of each to do anything against the data stored in a database. Definition See the file ibpp.h for an up-to-date definition of the interface. Lookup the IDatabase class.

reference:date

Thu, 30 Mar 2006 18:32:28 +0200

The IBPP::Date class represents a date value. It is not an interface class, with automatic smart pointer management like for instance the Database class. It is a plain classical C++ class. Use it to interact easily with DATE (SQL) columns in your databases.

reference:dbkey

Thu, 30 Mar 2006 18:36:58 +0200

The IBPP::DBKey class is used to hold a DBKEY, which is an opaque data type returned by the Firebird server when asked for the RDB$DB_KEY pseudo column. It is not an interface class, with automatic smart pointer management like for instance the Database class. It is a plain classical C++ class.

reference:driver

Wed, 07 Jun 2006 00:52:26 +0200

This is preliminary documentation regarding the unreleased version 3.0. The IBPP::Driver Interface represents a single instance of one Firebird or Interbase client library. It is through such a Driver instance that you will get all other interfaces of IBPP. So this is the most basic building block of any IBPP based host program.

reference:eventinterface

Sat, 27 May 2006 23:09:26 +0200

The EventInterface class is strictly an interface class. IBPP does not implement this class. To use the Events mechanism, you will have to derive a class from this one and implement its virtual ibppEventHandler() method. IBPP will call that method to notify the events occurences.

reference:events

Tue, 11 Apr 2006 14:53:39 +0200

The Events object allows easy interactions with the events mechanism offered by Firebird. One Events object represents a set of events, linked to one Database attachment. You really should also read the EventInterface article to grab a complete view on this topic.

reference:exceptions

Sun, 28 May 2006 11:11:02 +0200

IBPP reports errors exclusively through C++ exceptions. Return values of methods calls are never used to return success or failure. All exceptions classes thrown by IBPP derive from the std::exception class and re-implement their virtual method const char* what(), making it easy to handle those either globally of through dedicated catch handlers.

reference:guidelines

Thu, 30 Mar 2006 18:09:54 +0200

IBPP introduces a C++ name space : 'IBPP'. Everything is defined inside that namespace. Depending on your application needs, on your mood or if name clashing happens, you could do a :

using namespace IBPP;

in your program files, or choose to use the (short) prefix IBPP:: at a lot of place. The choice is yours. In these notes however, we will assume the second option : prefixing everywhere needed with 'IBPP::'.

reference:overview

Sun, 28 May 2006 13:52:47 +0200

Here is the overall big picture of the relationships between the various IBPP objects. Don't mis-read this graph: it is not a class derivation tree. The arrows show you the runtime dependencies of objects. The blue rounded shapes are the IBPP 'Interfaces'. You call their corresponding Factories to get instances of these objects. Except for Database and for Service, each Factory call requires one or multiple references to other existing object instances. These dependencies are shown by the arrow…

reference:samples

Sat, 27 May 2006 23:26:47 +0200

This section of the documentation drives you, without explaining all the details, through short program excerpts. The purpose is to show you the big picture : how you can create or connect to a database and start working with it. Compiling All your project files which use IBPP obviously need to include the library header file.

reference:service

Sat, 27 May 2006 23:14:53 +0200

The IBPP::Service Interface represents a single connection to the Firebird service manager. Such a connection is used for various maintenance work. Definition See the file ibpp.h for an up-to-date definition of the interface. Lookup the IService class.

reference:statement

Tue, 23 Jan 2007 16:58:44 +0200

The IBPP::Statement Interface is used to issue queries and other statements to a database, in the context of a transaction. So, along with IBPP::Database and IBPP::Transaction, it is the core of IBPP. You need at least one instance of each to do anything against the data stored in a database.

reference:time

Thu, 30 Mar 2006 18:34:35 +0200

The IBPP::Time class represents a time value. It is not an interface class, with automatic smart pointer management like for instance the Database class. It is a plain classical C++ class. Use it to interact easily with TIME (SQL) columns in your databases.

reference:timestamp

Thu, 30 Mar 2006 09:07:57 +0200

The IBPP::Timestamp class represents a SQL timestamp value. It is not an interface class, with automatic smart pointer management like for instance the database class. It is a plain classical C++ class. Use it to interact easily with TIMESTAMP (SQL) columns in your databases.

reference:transaction

Tue, 08 Mar 2011 19:46:26 +0200

The IBPP::Transaction Interface represents a transaction (!). Along with IBPP::Database and IBPP::Statement, it is the core of IBPP. You need at least one instance of each to do anything against the data stored in a database. Definition See the file ibpp.h for an up-to-date definition of the interface. Lookup the ITransaction class.

reference:user

Thu, 30 Mar 2006 18:38:09 +0200

The IBPP::User class holds the information that the Firebird server manages about a user. It is not an interface class, with automatic smart pointer management like for instance the Database class. It is a plain classical C++ class. It is used by some of the Service interface methods.

reference:version3

Mon, 29 May 2006 20:23:13 +0200

This is preliminary documentation regarding the unreleased version 3.0. Let's have a look to IBPP 3.0 structure. You can compare it with previous versions. Well, nothing big changed. The only real structural change is the addition of the Driver interface (in red in this 3.0 overview graph). Now, all the other interfaces have a runtime dependency to such a Driver instance. Think of it as older versions having an implicit single Driver hidden instance, while version 3.0 can have multiple, hence…