What's New in Firebird Ado Data provider for .Net and Mono

Release Candidate 1 ( 2005-02-XX )

Bug fixes (Please read the Changelog for details)



	* Fixed problem with 0 lowerbound array fields on the embedded server support.



	* Try to fix performance problem with array fields on selectable statements

	when working agsint the standalone firebird server.



	* Fixed problems with the new Design time support on Visual Studio 2003.



	* Fixed incorrect mapping for binary blob fields to System.Array, now it will

	be mapped to byte[]



	* Fixed char values checkings by using the field character set information

	for the check.



* Improved comments removal on the FbScript class. (Andreas Sandner)



* Integrated the BinaryEncoding class for the octets character set support (Contributed by Jim Beveridge)

* Added error information to the FbDataAdapter configuration wizard.

SAS is the company that comissioned the Vulcan port of Firebird

My name is David Shamlin; I am with SAS Institute, Inc (http://www.sas.com/). SAS is the company that comissioned the Vulcan port of Firebird. We are a business and analytic intelligence software vendor.



A year and a half ago we identified a business need to incorporate relational/ACID transaction storage capabilities into our platform bundle and decided to pursue an open source database solution that met our requirements. We chose Firebird because it supported an embedable database engine and implemented many of the SQL semantics our consumers need. Because our software platform runs on a number of 64-bit SMP operating systems, our first order of business was to create a Firebird port to one of these systems and introduce modest (i.e., multiple user requests executing in parallel) multi-threading capabilities to the engine. We entered into a partnership with IBPhoenix and with Paul Beach's help acquired the services of Jim Starkey to do much of the heavy lifting on the project for us.



In December of last year, Jim (with Ann's help) finished the initial phases of this work which has come to be refered to as the Firebird Vulcan project. During that time, we also had the opportunity to address some minor JDBC issues with Roman and discuss testing strategies with Pavel. Currently, SAS has three developers and a DBMS product specialist working full time with the Vulcan source. A couple of additional individuals are contributing on a part time basis to additional porting and testing efforts. We have an initial port to z/OS completed, and I hope to initiate ports to a couple more 64-bit Unix/Linux systems in the first quarter of this year.



SAS's intent since the beginning of the project has been to contribute to the Firebird open source project and continue to be an active supporter through direct development and possibly commissioning further coding projects in the future. Since Jim turned over his final work to us in December, we have accumulated a series of source code changes that address some bugs we've uncovered through our testing. At this point, we're interested in committing these changes to the new Vulcan repository on Sourceforge and would like to enter into a dialog with the Firebird project administrators on how we can most effectively accomplish that.



We're pleased with the results we have achieved with Firebird/Vulcan to date and excited about becoming an active participant in the Firebird project. I trust the community at large also sees the value inherent in Vulcan and will welcome SAS's contribution. We look forward to the opportunity to collaborate with the team and getting to know others involved with Firebird better.



I can be reached for direct follow up at david.shamlin@sas.com   and will continue monitor this mail list in case the group wishes to have a more public discussion.



Thanks for your attention -- David

--

R&D Director, SAS Institute, Inc

The Code Project - Embedded Firebird: Full-Featured Embedded Database with 2 MB Runtime

Firebird is an database with 20 years of history, full set of features (including transactions, stored procedures, hot-backup, excellent scalability, etc.) and a friendly open source license. It is an overlooked but compelling alternative to Microsoft Jet and Microsoft MSDE 2000/SQL Express 2005. Let's take a look how it can be used embedded in your desktop application. What makes Embedded Firebird ideal for embedding:

• The embedded runtime is <>
• The database file (it's just a single file) can have any name and extension. You can associate the extension with your application.
• The migration to a standalone server couldn't be easier. Just copy the database file to the server and change a connection string on your client.

Read more @ code project

Vulcan Merge

The strategy to merge Vulcan and Firebird 2.0 to form Firebird 3.0 will
probably be gated by a single central question: Will Firebird 3.0 use
the Vulcan provider architecture.

Firebird 2.0 consists of two main pieces: A client library and a server
executable (some platforms have an embedded engine packages as a plug
replacement for the client library). The client library contains a
Y-valve front-ending the remote interface. The server executable
contains the server code, the Y-valve, and an engine.

In the Vulcan provider architecture, the client library (Firebird.dll
or libfirebird.so) contains only the Y-valve. During the database
attach operation, the Y-valve, under control of a configuration files,
tries to load provider modules from an ordered list until one is able to
successfully attach the database. Vulcan currently has providers for
the engine, the remote interface, and a gateway to legacy Firebird and
Interbase. When the ODS is changed, Vulcan gets another engine
provider, retaining the old shared libraries (buildable only from a CVS
tag) for backwards compatibility. Finally, in Vulcan, the server is an
executable linked to the same client library as ordinary client programs.

The provider architecture has a number of advantages. One is the
ability to perform rolling upgrades. In Firebird 2.0, there are two
ways to provide access to databases with different ODSes. One is to
have the single engine support a variety of ODSes. The other is for the
user to balance two (or more) Firebird installs on the same system. For
former is constraining on development, leading to unnecessarily complex
code to straddle versions, while the latter shift the burden to the
user. The Vulcan provider architecture, on the other hand, allows us to
release a new engine version as a new provider, leaving the existing
engine(s) in place, with a tweak of the core configuration file. This
allow a single program to attach simultaneously two databases of
radically different ODS versions, for a single installation to straddle
versions, and for production and development versions to coexist on a
single system.

The Firebird Y-valve, on the other hand, is hard linked to a fix set of
subsystems managed with conditional compilation.

A further complication is that while the Vulcan Y-valve requires that
each provider be thread safe, the Firebird Y-valve assumes its
subsystems are not, initiating THREAD_ENTER/THREAD_EXIT synchronization
before every subsystem calls, leading to tight integration between the
Firebird Y-valve and engine. Imposing the Vulcan provider architecture
on Firebird 2.0 breaks the division of work between the Firebird why.cpp
and jrd.cpp, and forcing the same global reorganization I had to do for
Vulcan.

The provider architecture is, perhaps, the most important aspect of
Vulcan, providing a clear, clean mechanism to manage change. And change
is the one thing we can be certain of.

Vulcan Priorites

Vulcan's highest priority is Firebird 2.0 coexistence. Vulcan and
Firebird 2.0 should be serially shared database files. To this end,
Vulcan needs to bring its ODS up to that of Firebird 2.0. The Vulcan
ODS is based on a bastard snapshot of the Firebird 2.0 development tree
a year ago last December. To the best of my knowledge, and I may well
be wrong, the major difference is index structure. Vulcan desperately
needs Arno's extended indexes. The conversion shouldn't be difficult --
btr.cpp was lightly touched -- and while the page cache manager has been
heavily rebuilt, the macros used for interface has been redefined. The
second part of coexistence is making sure that Vulcan and Firebird 2.0
don't trip over each other. For better or worse, the requirement to
support fine granularity threading dictated a change to the lock manager
format, so actually sharing a database between Vulcan and Firebird 2.0
is out of the question. We should, however, make sure that Vulcan uses
a different lock file with an appropriately different header. I think
we also need to solve, for once and all, a strategy that ensures that
two engines never try to shared a database file using different lock
managers. I'll make this the subject of a different post.

I think the second priority is fixing the Linux/Unix build procedure.
The procedure in place is strictly ad hoc for my personal convenience.
It needs to support building outside of the source directories,
differential build for production releases, and support for hybrid 32/64
releases. The dependency on autoconfig is definitely a problem for
platforms that support both 32 and 64 bit executables. Buildgen is
design to generate "stuff" from component specific Visual Studio 7
project files. Right now it generates complete makefiles. I could also
be used in a more limited way to generate make include files to be used
with component specific, hand maintained makefiles.

The third priority is re-implementing the "execute sql" statement and
building a "services" provider. The Vulcan architecture has full
support for the services API in both user interface and the generic
provider class, but there isn't yet a services provider to field the
calls. The difficult problem is that the individual standalone
utilities that comprise the services module are a profound mess,
containing references to internal engine functions, engine threading,
engine thread data, and engine synchronization primitives, none of which
exist anymore. It's an open question of whether to the "services"
builds of the components or just start over. I don't know. Somebody
needs to do a careful investigation and make a recommendation.

The fourth priority is general improvements. This is include new
features and bug fixes from Firebird 2.0 and general upgrades of the
code, specifically including continuation of the engine mechanism
encapsulation process. The most important of these is the
transformation of the RSB mechanism into a proper C++ hierarchy.

Vulcan Joins Free World!

The Vulcan source code joined the free world last week when the CVS tree
moved to the Firebird tree on SourceForge. Vulcan is now under the same
administrative policies as the rest of Firebird. All new and
contributed Vulcan code has been submitted under IDPL. The source tree
also includes the "buildgen" utility necessary to build Vulcan on
non-Windows platforms.

A technical description of Vulcan is available at
http://www.ibphoenix.com/downloads/VulcanOverview.pdf, including a
description of missing and incomplete components. I urge anyone
interested in Vulcan to start with this paper.

Vulcan is currently available as source with build procedures for
Windows (Visual Studio 7, also know as Visual Studio .NET 2003), 32 bit
Linux, 64 bit Linux, and 64 bit Solaris (Forte compiler w/ pthreads).
Ann and the Pauls are working on binary installations which should be
available soon.

Another document, VulcanRules.html in the vulcan directory, lists a set
of project management rules for the Vulcan project. The project is now
part of Firebird, so the rules are now advisory, not obligatory. They
are, in my opinion, still good rules.

There is not yet a Vulcan release schedule, nor do I expect to see one
before Firebird 2.0 ships. The source tree is open for development,
however, including propogation of features and bug fixes, as individual
developers feel appropriate, from Firebird 2.0. I personally think it
would be useful if the Vulcan and Firebird 2.0 ODSes were brought into
sync. I do ask that developers announce their intentions before
beginning a task rather than waiting until code is ready to submit.

Vulcan development was a long hard struggle, but now it's time for
Vulcan to take it's place in the Firebird project to sink or swim on its
merits. I think its good stuff, and I hope you will, too.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376

Enterprises Warming Up to Firebird Open-Source Database

Evans Data Corp.'s Winter 2005 Database Development Survey looked at the database preferences of some 406 developers in mostly medium to large enterprises. Of those surveyed, 23 percent of developers picked Firebird for use in "edge" databases—in other words, those that are embedded in systems or in devices, such as a point-of-sale system in a retail outlet or a network device. Runners-up included Microsoft Corp.'s Access, at 21 percent, and Microsoft's SQL Server, at 13 percent.

RFID tagging will likely fuel interest in Firebird, said Joe McKendrick. McKendrick is an analyst for Evans, which is based in Santa Cruz, Calif.

http://www.eweek.com/article2/0,1759,1756876,00.asp

"Everything about Release 1.5"

A german Firebird 1.5 article entitled "Everything about Release 1.5" written by Thomas Steinmaurer is in the new edition of the German magazine "Der Entwickler". The magazine is available on February 3rd, 2005.

Global Temporary Tables

From Vlad Horsun:

Hi All !

During last two months i did some research and implementation of
global temporary tables. Here i want to show what i has done and listen
your opinions and critics.


Definition:

Global temporary table (GTT) is base relation with persistent metadata
definition, stored in database catalog (system tables), and temporary data.
GTT's can be two kinds - with data, persistent within connection or within
transaction only. Data from from different connection\transaction are isolated
one from others but metadata is common.


Syntax and semantics:

CREATE GLOBAL TEMPORARY TABLE
[ON COMMIT {PRESERVE | DELETE} ROWS]

Creates metadata for GTT and stored it in database catalog.
If optional ON COMMIT clause is omitted then PRESERVE ROWS is default.

CREATE GLOBAL TEMPORARY TABLE is usual DDL statement and
handled by the engine the same way as CREATE TABLE statement - when
issued all necessary entries made in system tables and when transaction
commited all other work are done by DFW. GTT differs from persistent tables
by two new flags in RDB$RELATIONS.RDB$FLAGS. ODS change not
required.

GTT's can have indexes, triggers, field and table constraints as permanent
tables. All constraints between any kind of permanent and temporary tables
follow the rule below:

a) references between permanent and temporary tables are forbidden
b) GTT with ON COMMIT PRESERVE ROWS can't reference on GTT
with ON COMMIT DELETE ROWS

There is a table for easyer understanding which references are allowed

Master: Permanent Preserve rows Delete rows
Child:
Permanent Allow
Preserve rows Allow
Delete rows Allow Allow

Domain constraints also can't reference on GTT.


Instantiation and cleanup:

GTT instance created when it first referenced, usually at statement
prepare time. Each instance has its own private set of pages on which
data and indexes are stored. When connection\transaction ends all
instance pages are released.


Storage:

Data stored on the same manner as persistent tables. At creation
time GTT has 2 pages allocated - primary pointer page (not necessary
actually) and index root page (all index definitions for GTT stored there).
Let call them "base" pages.

When GTT instance is created, engine allocate new primary pointer page
for it and index root page (this pages not tracked in RDB$PAGES) . "Base"
index root page are readed and all indexes from it created for given GTT
instance. All data\index operations with this GTT instance used this pages.

Storage can be inside database files or outside it. For external storage
purposes introduced concept of "page space" :

"Page space" is a set of pages enumerated from zero to 2^32-1 (SLONG)
on which engine can store all types of pages. Each page space reside in
it's own OS file or set of files. Engine has all necessary info about this files.

All database pages now reside within predefined "base" page space.
Pages of GTT's instances can reside within this "base" page space or within
additional page spaces created and dropped on the fly. Temporary page spaces
creation and deletion performed by the engine automatically. Files created
with "temporary" attribute set (on platforms which have such attribute).
"forced writes" set to "off" for temporary page spaces regardless of database
settings. All pages from all present page spaces are handled within common
page cache.


Blob "problem":

At blob creation time engine not know in which relation (permanent or
temporary) this blob will be attached when materialized. Therefore when blob
will be materialized may arise necessity to move it from initial ("base") page
space into page space of the appropriate relation. To avoid such waste of
time i propose extension of blob parameter block (used when blob created).
This extension allows to set initial page space in which blob pages will be
allocated before materialization. No public API change is necessary, only
few new constants.


Known limitations:

When user create new index already existing GTT's instances will not
know about it (and don't build it of course). Only new instances will read
new index definition from "base" index root page and build it.

This limitation seems not very important to me since this is usually
bad practice to change metadata on working database.


Work progress:

Almost all of said above is implemented in my private tree.

Current implementation allows to have follow kinds of storage for
temporary page spaces:

1. No temporary page spaces - all inside database
2. Page space per attachment
3. Page space per engine process (one common page space for SS or
separate page space per CS process)

Now it is hardcoded but can easy be moved into configuration file.
I have no strong opinion about how files for temporary page spaces must
be configured - where it must be created. Now i simple create each page
space in its own single file with predefined name:

sprintf(file_name, "fb_tmp_%x_%x", pid, hash);

where "pid" is process id and "hash" is hashed full name of primary database
file. Files are placed into GetTempPath(). As temporary solution and for testing
purposes its worked fine but for production use we must introduce some
rules for it.


Regards,
Vlad

Vulcan is now alive and well within the Firebird CVS tree on Sourceforge!

Vulcan is now alive and well within the Firebird CVS tree on Sourceforge. The Source Code can be downloaded and built from there using the module name of vulcan. For those of you who want to know more about Vulcan, we have prepared an overview document (.pdf), detailing the work that went into it, what still needs to be finished, how to build it and use it.

Security changes in firebird 2.0 - README.sha1

Alexander Peshkov Added File:

	README.sha1

Log Message:readme for security review

Content:

IF YOU GET MESSAGE "cannot attach to password database" TRYING TO START FIREBIRD AFTER UPGRADE FROM 1.5, PLEASE READ ~/upgrade/v2/security_database.txt.

WARNING! Firebird security level is still not satisfactory in one serious aspect, therefore carefully read this document before opening port 3050 to "big dirty" net.

Very important security problem of firebird, which is still unresolved - transmission of badly encrypted passwords (read - clear) across network. Unfortunately, it's impossible to solve this problem without breaking old clients, i.e. user who has set password using new secure way will not be able to attach to the server with old client. This fact (and plans to upgrade some aspects of API in next version) lead to decision not to modify way of passwords transmission in firebird 2.0. Fortunately, this problem may be easily solved using any IP-tunneling software (like ZeBeDee) to move data to and from firebird server (this is true for both 1.5 and 2.0) and this is recommended way to access your remote firebird server across internet.
Special attention was paid on the following aspects of security:
- none brut-force resistant passwords encryption in security.fdb;
- ability for any remote user (with valid account) to open security.fdb and read hashes from it (specially interesting in combination with previous point);
- inability for user to change his own password;
- no protection from remote brut-forcing of passwords on the server directly.
Lets have a look at the process of user identification in firebird 1.5. DES algorithm is used to hash password twice - first by client, next by server before comparison with hash stored in security database. But this sequence becomes completely broken when one SYSDBA changes password - client performs hash calculation twice and stores resulting hash directly in security database. Therefore hash management is completely client-dependent (or even better to say client-defined). To be able to use stronger hashes another approach should be used - hash to be stored on the server is always calculated by server side. And such schema already exists in firebird - this is services API. Therefore decision was made to use services API in any client activity related with users management. For today gsec and isc_user_add(modify,delete) API both use services to access security database (with exception of embedded access to POSIX CS, see below). Now it became quite easy to make any changes to way of passwords hashing - it's always performed by server. Should notice, that new gsec successfully works with old firebird versions - as long as server supports services, it's not a problem of gsec, how will be calculated the hash for security database, it simply asks services to do the work!
New hashing algorithm, selected for firebird 2.0, is SHA-1. Data, stored in PASSWORD field of security database, contains two parts - some random number, used as salt for calculating this particular hash, and hash itself (it's calculated as SHA1 (salt || username || password)). This method leads to the facts that (first) hash valid for user A is invalid for user B and (second) when user changes his password even to absolutely the same as later, new data is stored in PASSWORD field of security.fdb. This facts don't increase resistance to any attempt to brut-force password, but make "visual" analysis of stolen password database much harder.
One of the problems, solved during security review, was old gsec. Certainly, no one can change data in security database without correct password knowledge, but it's relatively easy to use old version of gsec. It will write bad old hash in PASSWORD field, and if LegacyHash parameter of firebird.conf is set to 0 (this is default, 1 should be used only during upgrade process), login to server becomes impossible. Therefore special measures were taken to make remote connection to security database impossible at all. Don't be surprised if some old program, trying to use such direct access, fails - this is by design, only services API (and isc_user_* API functions, in turn using services internally) may be used now to access users info.
Structure of security database was changed. In general, now it contains patch by Ivan Prenosil, enabling any user to change his own password. But there also some small differences. In firebird 1.5 table USERS had to be readable by PUBLIC - it was engines requirement, other case process of password validation failed. In Ivan's patch solution with view, having condition USER = '' in where clause, was used. That worked due to another bug in engine, which left USER SQL variable empty, not 'authenticator', as it might seem from engine's code. After fixing that bug, it was certainly possible to add condition USER = 'authenticator', which in short-term was OK, because normal username is always converted to upper case. But better solution was found, and now user authentication process does not depend from such tricks. As the result - non-SYSDBA user can see only his login in any user-management tool (gsec, any GUI, which uses services API). SYSDBA certainly has full access to manage users' accounts.
The chance left for hacker to break firebird installation is trying to brut-force password. Taking into account, that maximum password length is 8 bytes, this is a bit possible for firebird. Version 2.0 has protection from it - after too many attempts to enter wrong password authentication process is locked for a while, minimizing the chance of finding correct password during reasonable time.
POSIX classic server.
For some technical and historical reasons, this kind of installation is specially dangerous from security point of view. Users, having embedded access to databases, MUST be given at least read access to such critical place as security database. This is the main reason that no matter of the fact that in firebird 2 security database is protected from any remote access, use of enhanced password hashes in it was really required step. Imagine malicious user, having user-level access to firebird. He can easily steel security database, take it home and quietly brut-force old DES hashes! After it he can change data in critical databases, stored on that server - specially dangerous kind of attack. In firebird 2 such activity was made much harder to perform.
But embedded POSIX server has one more problem with security - services API on it uses that same command line gsec, as normal users do. Therefore this utility must have full access to security database. Luckily, the main reason to reason to restrict direct access to security database was protecting from use of old versions of client software. But it's quite unlikely to have old client and new server on the production box. Therefore current solution of giving full embedded access to local security database in embedded mode is not too dangerous.

New documents added to firebird 2.0 Unstable by Dmitry Yemanov

Changes can be traced in the What's new text file on sourceforge . Some documents are not added yet.

* SQL improvements: 

        1) Introduced SEQUENCE as a synonym for GENERATOR (as per SQL-99) 

        2) Added SQL-99 compliant NEXT VALUE FOR 

        3) Implemented REVOKE ADMIN OPTION FROM statement 

        See also:

        /doc/sql.extentions/README.sequence_generators

        /doc/sql.extentions/README.ddl.txt

* ISQL improvement:

        Command line switch -b to bail out on error when used in non-interactive mode. 

        Also,return an error code to the operating system. 

        See also:/doc/README.isql_enhancements.txt



* Context variables 

        Added support for context variables via RDB$GET_CONTEXT and RDB$SET_CONTEXT system functions 

        See also:/doc/sql.extentions/README.context_variables2



* SQL improvement:

        Allowed PLAN, ROWS and ORDER BY clauses in UPDATE/DELETE statements 

        See also:/doc/sql.extentions/README.select_expressions

        Added an equivalence predicate which behaves exactly as equality/inequality, but treats NULL = NULL as TRUE

        Syntax: A IS [NOT] DISTINCT FROM B 

        See also:/doc/sql.extentions/README.distinct



* More SQL improvements:

        1) Allowed FIRST/SKIP/ROWS/PLAN and ORDER BY clauses in views 

        2) Added CROSS JOIN (A CROSS JOIN B means something like A INNER JOIN B ON 1 = 1 or just FROM A, B) 

        3) Allowed UNION in subqueries and INSERT statement 

        See also:/doc/sql.extentions/README.select_expressions



* UDF improvement:

       Ability to signal SQL NULL via a NULL pointer 

       See also: /doc/sql.extentions/README.ddl.txt

       

* Expression indices:

       Implemented indices based on arbitrary expressions

       Syntax: CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]] INDEX  ON  (  ) 

       See also:/doc/sql.extentions/README.expression_indices



* IIF builtin function :

       Added IIF (, , ) as a shortcut for CASE WHEN  THEN  ELSE  END 

       See also:

/doc/sql.extentions/README.iif



* Improved ISQL:

       1) Fixed bug SF #910430 - ISQL and database dialect 

       2) Add SET HEADING ON/OFF option 

       3) Add -M2 command-line option to send output of statistics and plans to the same file than the rest of the output

       See also:/doc/README.isql_enhancements.txt



* New database shutdown modes are introduced Single-user and full

       shutdown modes are implemented 

       See also:/doc/README.shutdown_modes.txt



* Implemented EXECUTE BLOCK statement It is now possible to use dynamic PSQL with this statement 

       See also:/doc/sql.extentions/README.execute_block



* Implemented support for default parameters for stored procedures 

  See also:/doc/sql.extentions/README.default_parameters



* Re-worked logic of updatable views This solves problems with views that are implicitly updatable,but still have update triggers

        See also:/doc/sql.extentions/README.view_updates



* Added SQL200X ROWS clause New syntax to limit amount of records you want to get 

        See also:/doc/sql.extentions/README.rows



* Support for explicit cursor syntax in PSQL It is now possible to declare and use multiple cursors in PSQL 

  See also:/doc/sql.extentions/README.cursors



* Improved PLAN clause Allowed to specify more possible paths for the engine 

        Example: PLAN (A ORDER IDX1 INDEX(IDX2, IDX3)) 

        See also:/doc/sql.extentions/README.plan



* Added LEAVE syntax support PSQL loops now may be marked with labels and terminated in Java style 

        See also:/doc/sql.extentions/README.leave_labels



* Improved ROW_COUNT Now it's possible to get number of selected rows as well 

        See also: /doc/sql.extentions/README.context_variables



* Derived tables support Implemented support for derived tables in DSQL (subqueries in FROM clause) as defined by SQL200X 

       See also:/doc/sql.extentions/README.derived_tables.txt



* New backup technology Implemented fast on-line physical incremental backup facilities 

       See also: /doc/README.nbackup.txt



* Generic cleanup. Various cleaning and tidying up of code, warnings removal,64-bitness cleanup, numerous minor bugfixes

FlameExport 1.5.5 is released

FBExport V1.55 has been released and is available for download. FBExport is an open source command-line and GUI tool for exporting/importing data to and from Firebird and InterBase databases. It is based on the IBPP C++ library, and runs on both Windows and Linux

Imported vulcan sources into cvs

Pavel Cisar imported vulcan source into cvs on sourceforgeand then on Jim's request removed some of files

Testing Testing Testing Firebird

Pavel Cisar modified testing module (qmdb) with a new README

MySQL and Firebird battle for database top spot

Database developers are favouring Firebird and MySQL over PostgreSQL, according to new research.

The Evans Data Corporation survey of 400 database developers found that MySQL accounted for 40 percent of open source database deployments, while Firebird accounted for 39 percent. PostgreSQL accounted for 11 percent of deployments, said the survey.

Firebird database provider will be part of the next release of Mono 1.1.xx.

FireBird: Carlos Guzmán's Firebird database provider has been checked into CVS and will be part of the next release of Mono 1.1.xx.

Firebird SQL can be used either in server/client mode, or it can be embedded into your application to simplify configuration and deployment of smaller applications. Both modes are supported by Carlos' provider.

from mono blog

Developers who use Firebird in .NET

Developers who use Firebird in .NET should check http://www.dotnetfirebird.org

FireBird is the most used open source database for Enterprise applications

FireBird Soars into Database Deployments, New Evans Data; Survey Open Source Databases Usurp Market Share

SANTA CRUZ, Calif.--(BUSINESS WIRE)--Jan. 18, 2005--FireBird is making major inroads in the database space, according to Evans Data Corporation's new Winter 2005 Database Development Survey. FireBird is the most used open source database for Enterprise applications, more database developers use FireBird for single purpose applications and FireBird is tied for the most used database for workgroup applications. Further, MySQL and FireBird are locked in a virtual tie in the open source database space with each being used by just over half of database developers who use open source databases

more reading this link
update:
better url on evens data site

Firebird and Web Services - question

Anybody out there using firebird as a backend for "Web Services" ?

I have used FB for backend of web services and web sites for many years
using cgi/isapi and more recently C# with the fb .net privider.

Rgds

Si Carter

[ED: i think there is no problem using it from any language java,php . Webservices are open standards]