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]

Stored Functions idea on Firebird-Architect

From: Fabricio Araujo
Appear that some people would like
to implement some simple functions in
FB PL/SQL. There are some (easy/
not sloppy) way to implement something
like a CREATE FUNCTION statement
(will return a scalar type - varchar,
integers, floats, etc only one value).
No allowed to return resultsets.

That will make some simple functions
to be implemented as SQL functions
instead of the (trickier) UDF functions.

What do you think about?

and response From:Dmitry Yemanov

> I believe Dmitry has this already working
> in his private tree. The trick is to write
> a selectable procedure and to have DSQL
> automatically wrap it in singleton select.

Correct. Just for the record, I wanted true SQL
functions, not just an another call type for
procedures with single return parameter. So DSQL
parser should be extended to process new DDL properly,
as well as support RETURN clause (disallowing
SUSPEND/EXIT at the same time) and generate valid
selectable BLR. Also a minor ODS change is required
to clearly distinguish between procedures and functions.
I was about to propose the necessary stuff, but the
well-known "external procedures" talk happened exactly that
time and I've shut my mouth to have the external
stuff agreed on first, as these things are interrelated.
Now I'm not sure when and how we should
reopen this question. I just know that we definitely should.

Firebird Coding Style Again

Jim started a new thread about coding style (flamewar is on)

I'd like to explain why I use the coding style that I do, and why I think other people should use it as well. Many people argue that coding style isn't important as long as it's consistent. I disagree. Consistency is important and costs little, but other factors are even more important.

I’d also like to establish a rule for this discussion. Firebird is our project. We should choose a coding style based on our needs, not on the rules of some other authority. Coding style is an important element of software engineering that can be discussed rationally using logic and analysis rather than reference to authority, whether that authority was your professor, the editor of K&R, or Linus Torvalds. If any of those people wants to explain his preferred style, he should do it himself. If he doesn't want to defend it, I want to hear his arguments, not his name.

In a project like Firebird, a piece of code is written once, modified maybe a dozen times, but it will be scanned thousands of times by hundreds of individuals. Like most large software projects, Firebird has little comprehensive and accurate internal documentation. The basic structure is described in various places, but the final source of information is the code itself.

Some structure can be deduced from the naming conventions used for modules and functions, but old names are very terse because global symbols were constrained to 8 characters when I wrote the original code. In line comments certainly help, and I'm very happy to note a significant increase in comments since my original "terse" implementation. But the bottom line is that the best information on the code is the code itself, and anything we can do to make the code more accessible benefits everyone.

People study code in two distinctly different modes. Most often, they peruse - scan - the code quickly to get the general picture or to locate a particular piece of functionality. Much less often, someone will analyze a piece of code closely to isolate a bug or to revise or extend the function. Just about anyone can understand a modest piece of reasonably well-written code by detailed analysis. Close analysis is time consuming however the code is structured. Not all that much can be done to accelerate it. Code perusal, on the other hand, can be accelerated by reasonable coding practices.

The key to code perusal is following the flow of control. In most cases knowing that a particular block of code is handling a specific condition is sufficient. The actual handling isn't important until after the big picture has been mastered.

The primary tool for presenting control flow is judiciously used white space -- indentation and blank lines. I don't know who invented the idea of code paragraphing, but I suspect it evolved with Algol-60. Earlier languages like Fortran and COBOL had a strong line orientation. Algol introduced the concept of arbitrarily nested statements that, left to the highly creative, rapidly became unreadable. To an Algol compiler, an Algol program is a stream of lexemes. To a human however, something else was necessary to expose the structure of a program to a casual observer (or even to the author a week or two later). The solution that evolved was paragraphing.

The essence of code paragraphing is childishly simple --

1) code conditionally executed is indented under the code that controls its execution.

2) white space separates blocks of conditional code from the flow around it.

Trading white space for clarity was a bargain even when the cost of white space was more punch cards.

I've outlined what I consider sound coding practices in the Vulcan Rules document at the top of the Vulcan CVS tree. I'd like to go over some of the rules and explain why I consider them important.

Rule: Comments should have the same indentation as the code they document, and should be preceded and followed by blank lines.

Explanation: The indentation convention should be obvious -- comments need to follow paragraphing rules for the same reason code does. When you are scanning for the end of a block, you should not have to read every comment and code line. The purpose for separating comments from code with blank lines is less obvious. Good comments are not restatements of code. Over the years you’ve been programming, you’ve read a lot of comments like this:

mov r3,r4 ; move r3 to r4

When you are trying to understand a large body of code, comments that simply restate the code stop being just useless and become really annoying. If you need to know the implementation of the algorithm, read the code. If you need to why the value in r3 needs to be put into r4, that information should be available from the comment. Useful comments describe the motivation for a block of code -- what it's trying to do, not how it's trying to do it. These comments are clearer when set apart from the code. Likewise, the code is clearer when set apart from the comments. For a reader, the code and comments serve different purposes, and each needs to stand by itself.

Rule: The bodies of compound statements should be indented beneath the code that controls it. This means that the following is preferred:

if (trace)
printf ("something happened\n");

The style most commonly taught in programming courses is:

if (trace) {
printf ("something happened\n");
}

To my mind, this violates both graphic clarity and language structure. The substatement of the "if" is a compound statement itself containing a single statement. The substatement is subordinate to the "if" and belongs underneath and indented. Putting part of the compound statement on the same line as the "if" suggests that the brace is part of the "if". It isn't.

A more serious problem is that even the most dedicated brace-manglers sometimes omit the brace, which requires the reader, who just wants to scan the code checking flow control, to stop and read the entire "if" line, scrolling horizontally if necessary, to check for a brace to find the end of the "if" statement. This is an unreasonable amount of work. [A small note: Working software engineers almost never teach software engineering. Computer science curricula are run by a self-perpetuating, inbred organization unsullied with practical experience.]

Another school thought would write this snippet:

if (trace)
{
printf ("something happened\n")'
}

Again, this violates the logic of paragraphing. The braces are subordinate to the "if" and should be indented; the next line at the same level as the "if" should be line common to the various control paths through the "if" block. I also don't like braces where they aren't necessary as it reduces the amount of code one can see at a glance. After 40 years of programming, I'm afraid by reaction to a simple statement enclosed in braces is "Huh? Did the guy miss school the day they covered statements?” The same applies to:

if (trace)
{
printf ("something happened\n");
}

Ok, this is clear, the indentation makes logical sense, but the braces add nothing. While the purpose of paragraphing to clarify the code, it is reasonable to assume the reader knows the language.

Indentation is generally important, but absolutely critical for try/catch blocks. A careful reader is going to be constantly scrolling down to see how a thrown error is going to be handled. In many too many places in Firebird this involves counting braces on one's fingers and hoping for a comment on the critical brace indicating it's the end of the "try" block. In structured code, these comments are completely unnecessary.

The practice of putting "case" branches at the same level of indentation as "switch" is terribly confusing, particularly when used with nested switches.

Someone may argue that consistent indenting under if, for, while, switch, try, and catch moves the code too far to the right. A large block of white space on the left is the software gods’ way of saying that your code is too complicated. Rethink it. Consider a subroutine.

During the Borland years, the average length of a function went from maybe a dozen lines to over a hundred. In almost all cases, this is the result of bad design and bad organization. Simple code almost can't fail. Complex code with many levels of conditionals is almost always buggy.

Blank lines are an under-used resource. Vulcan rules put blank lines before and after all if statements, and most loops, switch, try, and catch statements. Research has shown that most bugs occur when two code branches converge with inconsistent state. The danger point is not the top of a conditional statement, but the bottom.

While doing Vulcan, I tried to change as little as possible. Time after time, however, I found myself re-paragraphing code so I could understand what it was doing. After a while, it became a habit -- if a block of code wasn't crystal clear, I cleaned it up. In many cases, I was reverting code to the style in which it was written. I will concede that the phrase "grrr -- code vandals --- grrr" passed though my mind during the process, particularly when some well-meaning soul rendered a piece of code unreadable.

Two things are clear with regards to coding style. First, there is great disagreement about what the proper style should be. And second, there will be great agreement that I'm completely wrong on all counts. So I'm going to ask people on the project to do two things. One is to take the time to understand my arguments, even you don't agree with them. The other is that you explain why an alternative is better, not who likes the alternative.

--

Jim Starkey

Firebird 1.5 Error Codes - posted

Firebird 1.5 Error Codes submited by Helen Borrie (PDF)





Full listing of SQLCODES, GDSCODES, Symbols and Messages, extracted from msg.gdb for use in "The Firebird Book"





DOWNLOAD Right-click to download as PDF

Update:
is located on the documentation page
A little hard to find :)

Scheduler option into Firebird ?

DY> Isn't it what e.g. cron is for? ;-)

Roman:
BTW, I do not agree to this. I believe that something like

CREATE TASK {AT | PERIODICALLY }
AS BEGIN
...
END

is much more simpler way to add task compared to creating a script and
adding a cron job to execute an SQL script. How to add this feature to
ClassicServer is another question (probably will not be an issue for
Firebird 3.0). Under which account with which rights to execute it, that one
more question to answer.

But that's my personal opinion.

and Jim's response:

Netfrastructure has such a feature. For better or worse, the schedule is expressed in CRON format extended with seconds. There are two schedulers, one for system tasks and one for user tasks. System tasks are things like the memory scavenger and the Java garbage collector. User tasks are used for replication, calendar notification, report generation, backups, etc.
A major difference between Netfrastructure and Firebird, of course, is that Netfrastructure has an internal Java Virtual Machine that the scheduler uses for scheduler wakeups. In the Firebird context, I don't think stored procedures have enough computational power to be as useful, but it would be a start.

As for rights, the solution is simple. A secheduled procedure runs with the rights of the user who scheduled it.

Borland Data Provider for Firebird 1.0 Alpha 4 released

Borland Data Provider for Firebird 1.0 Alpha 4 is availiable for download.



Download information can be found here:



http://www.firebirdsql.org/index.php?op=files&id=netprovider



This version was built against the Delphi 2005 BDP Assemblies.





This is an Alpha version, please, be patient and report the problems you have in the Firebird .NET Provider development list.



-- 

Carlos Guzmán Álvarez 

The Firebird Federation Data Archive

Since we all deal with a lot of common data it makes sense to provide an

archive where that data can be centralised. There have been various

discussions on things like postcodes, zip codes and the like, and

providing a means of combining data from several sources seems to be the

best way forward.



Since the Foundation only covers this planet, and I'm sure someone will

come up with inter-planetary records, we are probably creating a

'Federation' of data sources.



So far I have

COUNTRIES with ISO2 and ISO3 code

   - need to add dialing number/international ref no

GB_COUNTY

GB_TOWN

DE_STATE with state code

US_STATE with state code

CA_PROVINCE with code and space for flags

   - but then I could not load them  ;) 



Hopefully people get the idea, and I am sure we will be adding such

things as country flags, and other elements, but they will not be

compatible with a csv download  :(  So I suspect we will have an image

less view as an option for creating the csv extract.



I do have the GB Postcode list, but I'll refrain from posting that

1492000 records making 200Mb of data, and while it has been created from

sources I have control off, I'm not sure on the 'copyright' position

over postcode data. I will have an 'area' code list - the first half of

the postcode - but anything more accurate will need investigating.



Can someone with better SQL skills than me tell me if we can combine the

county/state/province tables to produce a world 'state' list as a view

on the other tables, or will I need to 'build' the larger table via

scripts and 'pump' the data?



Who else has some contributions?

Eating places in the Gamma Quadrant?



Of cause you all have access to Black Crystal communications, so you

know that the link is

username:demo

password:demo



http://ibWebAdmin.lsces.co.uk



I've created a second demo database with the information in, and

ibWebAdmin provides a csv upload/download, in addition to on line editing.



--

Lester Caine

-----------------------------

L.S.Caine Electronic Services

firebird 1.5.2 - debian status

I am in process of building firebird-1.5.2 packages. I used the 1.5.1 diff.gz as starters and then just fixed the failing hunks.

Also, I've fixed the lintian complains. These include:
1) short description starting with a capital letter (but see #288568)
2) non-dev packages containing symlinks to libraries, i.e. libfbclient.so -> libfbclient.so.1.5.1 These are moved in -dev
3) maybe others I can't remember.

Remaining lintian warnings:
1) about NMU - since I am not in the Uploaders: lintian thinks this is a NMU build. Should I include myself in Uploaders or just ignore the warning?
2) .dsc file contains strange architectures in Architectures: like "darwin-i386" and such. This comes from @arches@ in debian/control.in where it is replaced by the output of `type-handling i386 any'. I see 1.5.1-4 has the same list of strange architectures.

Unfortunatelly I have no hosting at hand. Is there a place I can upload the files for review/testing?



dam
--
Damyan Ivanov

Mandrake and Firebird

Good news !

Firebird.src.rmp is in the Mandrake cvs
http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/contrib-SPECS/firebird/

the guy from Mandrake made the job, so I hope we have a strong
probability to be in the next release of Mandrake.

Update:

the first rmp is in cooker

http://rpms.mandrakeclub.com/rpms/mandrake/devel/cooker/i586/media/contrib/firebird-1.5.2.4731-0.1mdk.i586.html

so Mandrake i586 users can have a try

-- Philippe Makowski

Firebird database readies SMP release

"Builder: The open source project, which was created when Borland open sourced Interbase in 2000, is due to release a version of its database with full SMP support allowing enterprises greater scalability..."

Read more@zdnet

Building Firebird 1.5.x on MacOSX

This page is an extract from a larger HOWTO entitled Firebird Relational Database on MacOSX .
These sections are posted here in the hope that someone can make immediate use of the info....

XML *IN* Firebird - question

Lester Caine is asking on Firebird-Architects :

The job for the new year is to make a better interface to the XML

schemas that I am being asked to process. Having already established

that we do not want to store raw data as an unprocessed flat file with

all the XML tags in place, the obvious next question is "How should we

store it".



I think the discussion here should be on a 'standard' way of processing

any XML schema such that we can map the information into additional XML$

system tables and be able to rebuild the schema from that. (*NOT* part

of the engine just yet , but perhaps something for FB6 or 7 ). This

would then provide a basis on which to build the data that goes with the

schema, while at the same time making it searchable in a relational way.



As a starting point, I am looking at genealogical data. I have a 2000+

grid of CAINE/HUM PHRIES family history in a GEDCOM format, which I

would like to convert to XML. Both are flat file with tags formats, so

the basic conversion is simple, but there is no agreement on an XML

schema yet for the data, so I am looking at a data model to store the

raw data in Firebird, which can then be extracted in which ever way the

final XML goes. *THAT* is when I realised that the architecture of how

to do it is much more important than the XML.



So the first element of the jigsaw, is probably a table of elements,

with a tree structure describing the links to source elements, and

fields for storing the format and pattern information. This should

perhaps be something that the 'XML Binary Characterisation Working

Group' should be looking into as part of the standard, but they seem to

be having trouble deciding who pays for the catering next time they meet ;)



So am I alone here, or am I on the right track. I am having fun at the

moment with the simple matter of managing locations in the genealogical

data. Every event has a location, but there is no means of populating

that location from a location table. *THAT* seems to me what is

fundamentally wrong with XML, or have I just missed the trick of how to

do it?



--

Lester Caine

Anyone still thinks we don't need 38-digit arithmetics?

it started as an problem description on firebird-devel



"Marco Kregar"  wrote:

>

> CREATE TABLE TEST (

>     V1  DECIMAL(18,4),

>     V2  DECIMAL(18,4),

>     V3  DECIMAL(18,4)

> );

>

> INSERT INTO TEST (V1, V2, V3) VALUES (10000000, 1, 1);

>

> SELECT V1*V2*V3 FROM TEST

>

> The select statement generate an unespected INTEGER OVERFLOW

This is by design. The resulting scale will be 4 + 4 + 4 = 12, to avoid any

precision loss. Since the maximum precision for NUMERIC is 18, it means that

only 6 decimal digits are allowed for the integral part of the result. Your

10M value overflows this limit.



Anyone still thinks we don't need 38-digit arithmetics?  ;-) 





Dmitry

planetfirebird.com - registered

it will sum up the firebird blogs (i think)

Nigel Weeks wrote:

> I own http://planetfirebird.com and http://planetfirebird.net.

> If anyone's got hosting to offer, I can make it happen!

> 

Firebird V1.5.2 is available

Firebird V1.5.2 for Linux and Windows has been released and is

available for download.



http://www.firebirdsql.org/index.php?op=files&id=engine

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_download_15



Other ports will follow in time.



The release deals with a number of bug reports and issues reported by users of Firebird over the last few months, (please see the

Release Notes for more detailed information).



http://www.firebirdsql.org/index.php?op=devel&sub=engine&id=rnotes0152_09&nosb=1





As well as wishing everybody a merry christmas and a happy new year,

the Firebird project now hopes to concentrate on Alpha releases of Vulcan and Firebird 2.0 in the New Year.



Regards

Paul Beach

Preparing for v2.0 Alpha

quote from devel list (Dimitry) :

"I've just committed the updated version of WhatsNew. Everyone who did some
development please review this document and extend it where you feel it's
necessary. I'd also expect some features to be documented in the README
format under the /doc directory in HEAD. This documentation effort of us
will significantly help Helen to create the first RelNotes draft.

If anyone has any urgent active work in progress, please let us know. I'm
going to update the version string tomorrow and hopefully tag the tree in
one week. If there's something I missed, feel free to remind.

Dmitry"

"Best Database Poll" - by LinuxQuestions.org

Another "Best Database Poll" - this one by LinuxQuestions.org. This is the poll that we lost last year to MySQL by one vote. You have to register to vote (quick, free) and, after voting, you won't see the results graph again until the poll ends.