The aim of these examples is to copy as closely as possible the equivalent C++ examples. The primary intention is to demonstrate how to make calls to the new Firebird OO API. For this reason they should not be considered examples of best practice.
Another alternative is MWA Software’s Firebird Pascal Interface https://www.mwasoftware.co.uk/fb-pascal-api
Firebird Java External Engine Plugin 1.0.0-beta-1 is now available for download https://github.com/FirebirdSQL/fbjava/releases/tag/1.0.0-beta-1
There is now an official preview release – v0.5.0 – available on PyPI:
All core driver functionality works, except handling of limbo
transactions due to error discovered in Firebird (should be fixed in
soon to be released Firebird 3.0.6).
This preview version was released because the driver architecture is
evolving rapidly, and I would like get some feedback before the initial
release planned for end of June.
Some important notes about the driver architecture:
- It uses namespace package “firebird”, and the driver is distributed
as “firebird.driver” package. There are other packages that share the
same namespace: “firebird.base” and “firebird.butler”. In future I’d
like introduce “firebird.lib” package for extension libraries (former
schema, monitor and other extension modules in FDB).
- Although the initial driver design was close to FDB, there are
significant differences and the driver architecture and API will diverge
further from FDB or KInterbasDB. The sole backward “compatibility” is
defined as compliance to Python DB API 2.0. So the new driver is not and
will not be a drop-in replacement for FDB.
Here are some main decisions related to implementation and architecture:
a) Safe use. This translates to extensive use of type hints and
annotations, including Protocols etc. Also many arguments are defined as
keyword only to avoid ambiguity and improve code readability. This is
one from main reasons why Python 3.8 is minimal version required.
b) Wrong run-time conditions (like not closed connection) and some
arguments are checked ONLY as asserts. So optimized Python code does not
performs any such checks. Note that used trace/audit could be also
affected by optimization (depends on how you use it, see firebird-base
documentation for details).
c) Compact code. It often means that latest Python features are used
anywhere it makes sense (that includes := operator etc.).
d) Simplicity. This for example also means minimal number of names
defined, so all various constants and flags used by Firebird API are
defined as Python enums/flags. That same apply to number of function
parameters (with few exceptions).
- The driver uses “firebird.base” package, which is a collection of
modules that have general applicability, like extended configuration,
context-driven logging and trace/audit, hooks, work with structured
binary buffers, extended data structures etc. See:
and raw documentation at https://firebird-base.rtfd.io/
This package is a shared base for current and future Python development
projects under Firebird Project umbrella (currently the driver, soon the
Saturnin and QA suite etc.)
The driver uses almost all features provided by “base” package, but
specifically the use of hook mechanism and context-driven logging and
trace/audit are potentially the most valuable improvements, so any
usability feedback would be appreciated. I also plan to take advantage
of extended configuration, so any ideas or suggestions about driver’s
configuration options would be appreciated.
- With release of Firebird 4.0 beta 2, I started to adapt the driver to
new Firebird version. Part of this adaptation is new architecture that
moves some functionality into separate “inner” classes, so it could be
switched at run-time according to used Firebird version (or ODS). So
far, all information-related functionality (methods and properties) in
Connection and Transaction was moved out into “Info” objects, accessible
through “info” property (i.e. Connection.info. etc.). The
Services class was renamed to Server, and over next month I’ll move out
all services-related functionality into series of separate
domain-specific inner objects like “backup”, “config”, “trace”, “users” etc.
The reference documentation is here:
- Please note, that FDB is now considered as legacy driver, and its
development will be discontinued together with 2.5 once Firebird 4.0
will be released later this year. However, one FDB maintenance release
is planned before that, so if you have any pending issues or pull
requests for FDB, please let me know.
« Hide it
Django-Firebird changes : The stable version corresponds with django 2.2 and lives into stable/2.2.x branch. The current master branch of this repository is being developed under django 3.0.x.
django-firebird 2.2a1 is also published to pypi https://pypi.org/project/django-firebird/2.2a1/
MWA Software is pleased to announce that release 2.3.4 of IBX for Lazarus is now available for download from https://mwasoftware.co.uk/ibx.
This is the first update in over a year and provides a consolidated set of minor bug fixes. The changelog for IBX itself is available from here and the changelog for the Firebird Pascal API is available from here.
The next release of IBX should be available in the near future and will focus on support for the forthcoming Firebird 4. It will provide support for the new Firebird data types including TIMESTAMP WITH TIME ZONE and extended precision numerics (DecFloat).
Firebird Editor Pro 5.0.1 is released with the following changes :
Version 5.0.1 (May 25, 2020)
- Fixed AlphaControls
- Fixed lower case object name support
- Fixed options
- Fixed shortcuts
Mark Rotteveel and documentation team migrated the first documents to asciidoc
– Docbuilding Howto
– Docwriting Guide
ps: Since May/June 2020, the Firebird documentation project has switched to AsciiDoc for its documentation. This section gives a short overview how AsciiDoc is used by the project.
Firebird driver is updated with Support for Laravel 6 & 7
As Pavel Cisar promised at Firebird Conference in Berlin, the Firebird has brand
new DB API 2.0 driver for Python. It’s part of modernization campaign
that shakes off the legacy that goes back to KInterbasDB and Firebird 2.0.
Please note, that his new driver requires Firebird 3+ and Python 3.8+.
This “high” base line was chosen deliberately, to use all new features
available from latest Firebird & Python releases without constraints and
limits that backward compatibility would require. Internally, the driver
uses new client API based on interfaces introduced by Firebird 3. This
new API has many limits raised (like statement sizes, blob sizes etc.)
or completely lifted (like number of databases participating in
distributed transaction), and provides access to new Firebird features
(like scrollable cursors).
The initial release (v0.5.0) supports all key driver features you know
from FDB (passes all tests for FDB features), with next exceptions:
– distributed transactions (will appear in next version)
– FDB extensions like schema, monitoring tables and log parsers. These
modules will be developer later, and released as separate package.
New features in comparison to FDB:
– scrollable cursors
– type hints everywhere
– new FB client API instead old one
– enhanced Enums and Flags classes instead isc_* constants
– better and more rich support for Firebird services
The driver has also much cleaner structure and namespaces, and less core
code than FDB, and although it was not measured yet, it should also
perform better. However, the driver API is not 100% backward compatible
Right now, the new driver is available only from project’s GitHib at