FBSimCity v0.9.0: the machine room — the real Firebird engine inside the explorable city

FBSimCity, the explorable isometric city of Firebird internals, is at v0.9.0 — and this one adds the thing the project has been circling since it started. The city has always carried the same caveat: it is a model, it parses no SQL, and no Firebird code runs in your browser. The new machine room is the other thing.

The machine room

The machine room runs the actual Firebird engine: version 6.0.0 of the embedded engine, compiled to WebAssembly by Electric Firebird the way PGlite does it for PostgreSQL, in a worker on the page. No server, nothing uploaded, and the database kept in IndexedDB so it survives a reload. On top of it sits a SQL workbench and six guided sequences, each one ending in a number you can hold against something the city draws:

• SELECT CURRENT_TRANSACTION FROM RDB$DATABASE, twice — watch the id advance.
• OIT, OAT and Next straight out of MON$DATABASE — the same three markers the city draws over the transaction yard.
• Two UPDATEs to one row, then MON$RECORD_STATS back-version reads and purges — multi-generational architecture, counted by the engine.
• RDB$RELATIONS — the catalogue is ordinary tables.
• MON$IO_STATS fetches against reads — exactly what the cache plaza draws.
• The MON$DATABASE settings list — no log setting in it, because there is no log.

Every verdict is computed from what the engine actually returned, so a sequence can tell you the answer was not what was expected. The page also states what the runtime cannot show: one attachment means there is no second session to queue behind, so no lock wait to watch; there is no replica; and gbak and nbackup are separate programs against a file that does not exist there.

A correction to v0.8.0

v0.8.0 shipped a page saying this embed was impossible, and it measured an iframe reporting not cross-origin isolated to prove it. The reasoning was right up to the last step. The engine is built with threads, so it needs SharedArrayBuffer, which browsers hand only to a cross-origin isolated page, and GitHub Pages will not send the COOP/COEP headers that grant isolation.

What I missed is that a service worker can synthesise those headers for any page that ships one — including this project's own — and that both projects publish to mariuz.github.io, so the engine's assets are same-origin and need no CORP header under require-corp. The old measurement was real. The iframe was not isolated because the page doing the framing was not isolated either, which was the part I never tested. The engine page now records the mistake rather than quietly dropping it.

Also in v0.9.0

• The city used to load cold. Every cache slot empty, one version per tower, and the markers sitting exactly where they were initialised. It now warms 25 model seconds before the first frame. A database that has never run is not a neutral starting point — it is a state you will never meet.
• Six touch and camera defects, found after reading how PGSimCity fixed the equivalent: pinch zoomed about the canvas origin instead of the fingers, two-finger pan was discarded entirely, a third finger landing jumped the city, touchcancel was unhandled, a pinch fought the camera fly-to, and keyboard +/− drifted the same way.
• The readouts are now checked against the model behind them, and the throughput figure against independently counted completions. A gauge that wanders will happily paint a healthy city red.

And v0.8.0, for anyone who missed it

Keyboard navigation through every district — Tab and Shift+Tab walk them in pipeline order and announce each one through an aria-live region, which the city needed because it is a canvas and everything in it was mouse-only. Plus a fuzzer over 324 knob combinations, a soak, and enforced documentation coverage.

287 assertions, all passing. The suite runs in the browser with no framework and no build step: mariuz.github.io/FBSimCity/test/

City: mariuz.github.io/FBSimCity
Machine room: mariuz.github.io/FBSimCity/machine
Release notes: v0.9.0
Source: github.com/mariuz/FBSimCity (MIT, plain HTML/JS, no build step)

It remains a model for intuition, not an emulator. What is real, merely scaled, or a plausible stand-in is written down in the knob audit, along with the places the model is kinder than Firebird and the places it is harsher. Corrections are very welcome and do get acted on — the whole replication model was rewritten in v0.6.1 after Dmitry Sibiryakov pointed out on firebird-general that a synchronous replica which dies does not hang commits; it stops replicating and lets them through.

FBSimCity is an independent educational project, not affiliated with or endorsed by the Firebird Project. Firebird® is a registered trademark of the Firebird Foundation Incorporated.

Firebird Adds an Optional Static fbclient — and Solves the Symbol-Collision Problem Properly

Firebird's client library, libfbclient / fbclient.dll, has always been distributed exclusively as a shared library. PR #9104 by Adriano dos Santos Fernandes, merged into the Firebird source tree on July 24, 2026, changes that: it introduces an optional, non-default static archive (libfbclient.a on POSIX, fbclient_static.lib on Windows) for applications that need to link the client library statically instead of loading it as a shared object/DLL.

Why static linking wasn't offered before

The blocker wasn't packaging — it was memory management. Firebird overrides the global C++ operators operator new, operator new[], operator delete, and operator delete[] (in src/common/classes/alloc.cpp) so that any bare, non-pool allocation inside Firebird is routed through its own internal memory pool.

In the shared library, this is harmless: a POSIX version script (and a Windows .def file) keeps those overridden symbols hidden, so an application linking against libfbclient.so or fbclient.dll keeps its own global allocator untouched.

A static archive has no such boundary. Its object files get merged directly into the host application at link time, so the linker would silently resolve the host's own bare new/delete calls to Firebird's internal definitions — hijacking the host application's memory allocation without any warning. That's a nasty, hard-to-diagnose class of bug, and it's exactly why a static build was never shipped.

The fix: rename every internal symbol at the archive level

Rather than hand-maintain a list of symbols to hide, the PR takes a systematic approach: every internal global symbol not part of Firebird's public API gets renamed with a __fbclient_ prefix as a post-processing step on the compiled archive. This covers the global operators, decNumber symbols, C++ mangled names, vtables, typeinfo, guard variables — everything — generated automatically from the existing export list rather than curated by hand.

On POSIX (Linux and macOS), this happens in two steps:

1. Archive slimming — ld -r with -u flags seeded from every symbol in builds/posix/firebird.vers pulls in only the archive members actually reachable from the public API, using cross-reference output (--cref on ELF, -map on Darwin) to identify and repack just those members.
2. Symbol renaming — objcopy --redefine-syms (GNU objcopy on Linux, llvm-objcopy on macOS) renames every non-API global symbol to a __fbclient_-prefixed name, using a rename map generated automatically via nm --defined-only -g.

Both platforms share a single helper script, static_client.sh (autoconf-generated from builds/posix/static_client.sh.in), differing only in which cross-reference flag ld uses.

On Windows, the equivalent pipeline runs via a new fix_fbclient_static.bat: it parses builds/win32/defs/firebird.def for the public API, runs llvm-nm on every object file to collect defined symbols, builds the same kind of rename map (preserving __stdcall @n decoration where relevant), and applies it with llvm-objcopy --redefine-syms.

Regular pool-based allocation via FB_NEW / FB_NEW_POOL — the pattern used throughout the Firebird codebase — was never affected by any of this, since it never touched the global operators in the first place.

A side effect: no DllMain on Windows

A statically linked fbclient has no separate DLL module, so DllMain (previously in src/jrd/os/win32/ibinitdll.cpp) never runs for it. Most of what DllMain did turns out to degrade safely without it — config-root lookup falls back to the host executable's path, and loader-lock hazard checks simply don't apply to a statically linked EXE.

The one real gap was per-thread cleanup, which used to run only from DllMain's DLL_THREAD_DETACH notification. The PR closes it with a new ThreadCleanup class (src/common/classes/ThreadCleanup.h/.cpp) that uses Fiber-Local Storage (FlsAlloc / FlsSetValue / FlsFree) on Windows — mirroring the destructor semantics pthread_key_create already gives the POSIX build for free, and working identically whether the code ends up in a DLL or linked directly into the host binary.

Building it

POSIX:

make -C temp/debug TARGET=Debug client_static

produces <firebird>/lib/libfbclient.a from the same object set as the shared library (yValve + remote client + common). Most third-party dependencies (tommath, tomcrypt) still need to be linked separately by the consuming application; decNumber/libdecFloat is the one exception — it's small and vendored in-tree, so it's merged directly into the archive.

Windows:

builds\win32\make_all.bat CLIENT_ONLY=STATIC

builds yvalve as fbclient_static.lib under new DebugStatic / ReleaseStatic configurations, then runs the symbol-fixup script automatically.

Verification is straightforward with nm/llvm-nm: the public isc_* API stays global, while global operators (_Znwm, _ZdlPv, etc.) and internal symbols like decNumberFromString disappear from their original names entirely — replaced by __fbclient_-prefixed equivalents.

What's in the diff

25 files changed, +2168/-268 lines, across three commits:

• .github/workflows/static-build.yml — new manual CI workflows to build and validate the static client on Linux, macOS, and Windows.
• builds/posix/static_client.sh.in, builds/win32/fix_fbclient_static.bat, builds/win32/compile_static.bat — the new post-processing pipeline.
• builds/win32/msvc15/*.vcxproj*, *.props — new Debug/Release static configurations wired into the Visual Studio solution.
• src/common/classes/ThreadCleanup.h/.cpp — the new FLS-based thread cleanup, replacing the old DLL_THREAD_DETACH path.
• src/yvalve/MasterImplementation.cpp, utl.cpp, src/common/os/win32/mod_loader.cpp, src/jrd/os/win32/ibinitdll.cpp — call sites updated for the DLL-less code path.
• doc/README.StaticClient.md — new, thorough documentation covering the rationale, build steps, and verification commands for both platforms.

For any project embedding Firebird's client library directly into a host binary, this closes a real gap — and it does it without punting the symbol-collision risk onto the integrator.

Source: FirebirdSQL/firebird PR #9104

FBSimCity v0.6.0: the replication district — journal segments, commit order, and a synchronous replica that dies

Correction (added 9 August 2026): the section below headed “A synchronous replica that dies hangs commits” is wrong. Dmitry Sibiryakov pointed this out on firebird-general, and the source confirms it. In src/jrd/replication/Publisher.cpp, checkStatus() is called with canThrow = false on the commit path, so it cannot throw; disable_on_error (default true) instead clears the replicating flags, disposes the replicator and logs STOP_ERROR. The commit succeeds and replication tears itself down.

The reason it can do that without misleading anyone is the part I had missed: Firebird’s synchronous replication is not two-phase commit, so there was never a durability guarantee to protect. The real failure mode is arguably worse than the hang I described — replication stops, commits keep succeeding, nobody is told, and the replica quietly rots until somebody notices. Fixed in v0.6.1. The original text is left below unchanged.

FBSimCity, the explorable isometric city of Firebird internals, is at v0.6.0 with a new replication district.

Replication without a log

Firebird has no write-ahead log to ship, so its replication is logical — and it has to be. As each transaction commits, the changes themselves are written into a replication journal segment. When a segment fills it is sealed and queued for the replicator, and a new one opens behind it. Crucially the segments preserve commit order, so the replica replays history exactly as the primary lived it.

• Journal Yard — where commits are journalled. If the segments cannot be shipped, they stack up here visibly.
• Replicator — asynchronous ships at its own pace and the replica trails, so commits never wait. Synchronous makes the commit itself wait, so the primary runs at the speed of the slowest replica.
• Replica Database — a second database, drawn as its own shallower excavation, replaying the journal in commit order with its applied history filling in as it catches up.

Set the replica slow and watch lag build, or unreachable and watch the segments pile up: run the replica-lag scenario. Bring it back and it resumes from the oldest unshipped segment, in order.

A synchronous replica that dies hangs commits

This is the behaviour I was most careful to get right. A synchronous replica that becomes unreachable does not quietly fall back to asynchronous. Silently downgrading would mean claiming a durability guarantee the configuration no longer has, so commits hang instead — which is the honest behaviour, and the reason synchronous replication is a decision rather than a default. Watch it happen.

A fourth operator decision

The replica is gone and its journal segments are accumulating on the same volume the database writes to. Stop replication and discard the backlog, and the disk stops filling but the replica needs a fresh restore rather than a resume. Keep journalling, and nothing is lost if it returns soon — but you are betting free space at a steady rate, and if the volume fills the primary stops too, which is a far larger outage than the one you were protecting against.

Both answers cost something, and the verdict quotes numbers measured from the run.

Also in this release

• The test suite grew to 131 assertions, including commit-order preservation and in-order catch-up after an outage. It caught the two new scenarios being undocumented before this shipped, and a version mismatch between data.js and the on-screen badge.
• The top bar had been silently wrapping to two rows on narrower screens, a regression that crept in one button per release. It is a single row again.

City: mariuz.github.io/FBSimCity
Release notes: v0.6.0
Source: github.com/mariuz/FBSimCity (MIT, plain HTML/JS, no build step)

It remains a model for intuition, not an emulator. What is real, merely scaled, or a plausible stand-in is written down in the knob audit. Corrections very welcome, particularly on the replication mechanics, which I modeled from the documentation rather than the engine source.

FBSimCity is an independent educational project, not affiliated with or endorsed by the Firebird Project. Firebird® is a registered trademark of the Firebird Foundation Incorporated.

node-firebird catches up: roadmap complete, issue tracker at zero

Big news for anyone using Firebird from Node.js: the pure-JavaScript node-firebird driver shipped eight releases in under a week (v2.6.0 → v2.14.0), completing its entire roadmap and closing all 47 open issues — some dating back to 2015.

The driver now stands at feature parity with the best Node.js drivers for Postgres and MySQL, while staying pure JavaScript with zero native dependencies. It supports every server from Firebird 2.5 through the 6.0 snapshots, tested on Node 20–26.

Highlights for Firebird users

Firebird 6.0 Protocol 20, fully supported (v2.10.0). The long-standing Protocol 20 prepare hang was root-caused and fixed; Protocol 20 is now negotiated by default on Firebird 6 servers, including per-column schema metadata and the new owner option for CREATE DATABASE (firebird#7718).

The sporadic Srp failure, solved (v2.8.1). Srp/Srp256 attaches randomly failed with "Your user name and password are not defined" on ~1.2–1.7% of connections. Two SRP proof-serialization mismatches with the engine were fixed — 0 failures in 1000-attach loops afterwards. If you run Firebird 3+ with retry-on-attach workarounds, you can retire them.

Real single-byte codepage support (v2.13.0). WIN1250–WIN1258, ISO8859_2–9/13, KOI8R/KOI8U and DOS866 now encode and decode correctly — columns, parameters, literals and blobs. This also fixed parameters being silently sent as UTF-8 on non-UTF8 connections, and made the stock employee.fdb queryable under the default UTF8 connection.

Firebird 4 batch API put to work. Bulk inserts via executeBatch (v2.7.0, typically 5–10× faster than row-by-row) and a new batchStream writable stream (v2.13.0) — the COPY FROM analogue, with backpressure and all-or-nothing transaction semantics.

Replication-ready pooling (v2.14.0). Firebird.poolCluster targets primary/replica topologies built on Firebird 4+ logical replication: per-node pools, transparent failover, round-robin selection and node lifecycle events. Rounded out by pool events, live metrics and idle reaping (v2.8.0).

Modern API ergonomics. Injection-safe tagged-template queries, savepoints, affectedRows/result metadata via withMeta, server warnings surfaced as events, nestTables for JOIN column collisions, query cancellation with AbortSignal, first-class ESM, and ISC_USER/ISC_PASSWORD environment defaults.

One thing to check

Versions 2.7.0–2.9.0 serialised parallelWorkers with the wrong DPB tag — isc_dpb_set_db_replica — silently switching the attached database into replica mode. Fixed in v2.10.0; if you used that option, check MON$REPLICA_MODE on your databases.

Get it

npm install node-firebird

• GitHub: github.com/hgourvest/node-firebird
• npm: npmjs.com/package/node-firebird
• Releases & changelogs: github.com/hgourvest/node-firebird/releases

The issue tracker is empty and waiting for your feedback.

FBSimCity v0.4.0: the backup yard — gbak pins the OIT, nbackup fills the delta

FBSimCity — the explorable isometric city of Firebird internals — is at v0.4.0, and this release adds a whole backup yard, built around what gbak and nbackup actually do.

gbak: the backup that pins your OIT

gbak takes a logical backup online: it attaches like any other client and reads every table through a snapshot transaction. That snapshot is the interesting part — it pins the OIT for the entire run. Garbage collection stalls, cooperative GC refuses to demolish anything, and the record version towers climb until the backup finishes.

This is why a nightly gbak against a busy database and a mysteriously bloating database are so often the same story. Now you can watch it happen instead of inferring it from gstat -h:

Run the nightly gbak scenario →

nbackup and the difference file

nbackup is the other half: a physical backup, incremental by level. Level 0 copies the whole file, level 1 only the pages changed since level 0, and so on. The chain is enforced in the model just as it is in reality — ask for a level 1 without a level 0 and it refuses, and Restore chain reports which levels a restore would have to apply, in order. Lose level 0 and the rest are waste paper.

Locking the database (nbackup -L) freezes the main file so it can be copied safely while the server keeps running. Every page written from that moment lands in the difference file instead — a new orange pit beside the main excavation that fills up visibly and merges back on unlock. Forget to unlock, and it grows for as long as you watch:

See a locked database filling its delta →

Dirty pages stopped being free

I also fixed a genuine falsehood in the simulation. Evicting a dirty buffer used to cost nothing, which quietly understated write pressure. It now writes the page out first, so a reader that needs a frame pays for somebody else's write.

The interesting consequence is what it does not do. Because commits flush their page under forced writes (Firebird's default), dirty evictions stay rare on a healthy database — around 1% of evictions — and only start biting when the cache is too small for the working set, reaching about 5% at 16 buffers. The honest lesson is "your cache is undersized", not "writes are bad", and the new evictions (dirty N) readout shows exactly that.

A knob audit

Since the whole point of this thing is intuition rather than emulation, v0.4.0 also documents itself. docs/KNOBS.md lists every control and readout, what it does to the model, and whether the mechanism is real, merely scaled, or a plausible modeled stand-in — followed by the deliberate simplifications, written down so nobody has to discover them by reading sim.js. Sweep here is time-triggered rather than transaction-gap-triggered; lock contention is a probability, not a wait-for graph; no SQL is parsed. It is all in the table.

Also in this release

• Subsystem controls now live on the subsystem: start a sweep from the GC depot, run backup levels or lock the database from the nbackup vault, forget to commit a transaction from the Transaction Hall.
• The screenshot driver no longer leaks browser profiles, and form controls are 16px so iOS Safari stops zooming the page.

City: mariuz.github.io/FBSimCity
Release notes: v0.4.0
Source: github.com/mariuz/FBSimCity (MIT, plain HTML/JS, no build step)

Corrections are very welcome, especially on the backup mechanics — I modeled those from the documentation rather than from the engine source.

FBSimCity is an independent educational project, not affiliated with or endorsed by the Firebird Project. Firebird® is a registered trademark of the Firebird Foundation Incorporated.

FBSimCity: an explorable city that shows how Firebird works

I've published FBSimCity, an interactive visualization of Firebird internals: an explorable isometric city where every building is a subsystem from the classic Conceptual Architecture for Firebird paper (Chan & Yashkir), and queries commute through the pipeline as glowing particles — REMOTE harbor → Y-valve → DSQL → JRD, with the lock manager tower watching over it.

The simulation is Firebird-flavored throughout:

• MGA record versions stack a floor on a tower with every UPDATE, and the towers redden as chains grow.
• Next / OAT / OIT counters run live on the Transaction Hall facade. Flip on a long-running transaction and watch the OIT pin garbage collection while the version towers pile up — Firebird's version of bloat, visible in about twenty seconds.
• Cooperative GC and a sweep truck tour the tables, correctly refusing to demolish anything the OIT still protects.
• A page cache flashes hits and misses above the excavation that is the database file, where careful write ordering — not a WAL — keeps things consistent.
• Lock waits and deadlock rollbacks queue at the lock manager tower.

Version 0.3.0 adds a live version-chain inspector: click the Record Version Towers and watch the busiest table's chain update in real time, each version tagged with the transaction that wrote it and marked reachable or garbage against the current OIT. There is also a guided tour, a step-by-step query trace that walks one UPDATE through every station, six scenario presets (cache thrash, stuck OIT, lock contention, rush hour...), and a data-page anatomy diagram.

If you prefer reading to clicking, The life of a query is the same sixteen-station pipeline as an accessible, keyboard-navigable page that works with a screen reader.

You can share a reproducible state with deep links, for example this one drops you into a stuck-OIT city fifty simulated seconds in, with the chain inspector already open.

Try it: mariuz.github.io/FBSimCity
Source: github.com/mariuz/FBSimCity (MIT, plain HTML/JS, no build step, no dependencies)

Inspired by PGSimCity, the PostgreSQL equivalent. It is a scaled model for intuition, not an emulator — no SQL is parsed and no Firebird code runs in your browser — so corrections from people who know the engine internals are very welcome.

FBSimCity is an independent educational project, not affiliated with or endorsed by the Firebird Project. Firebird® is a registered trademark of the Firebird Foundation Incorporated.

#gsoc2015 for libreoffice update #2 - update firebird to 2.5.4 , osx builds ok

I have updated firebird 2.5.4 patch also with osx patches refactored (now is building ok on osx)






https://drive.google.com/file/d/0BwmDDYc8dMVzRllXM0pMYWRhWlpiOGRZSDNmMkxfekV2QlI0/view?usp=sharing



I still need to clean the cygwin msvc patch (work in progress)


it fais on cygwin on these lines






2 out of 10 hunks FAILED -- saving rejects to file configure.in.rej


[build CHK] cppu


1 out of 2 hunks FAILED -- saving rejects to file src/jrd/gds.cpp.rej


1 out of 1 hunk FAILED -- saving rejects to file src/jrd/os/win32/mod_loader.cpp.rej


[build CHK] cppuhelper


Patch FAILED: C:/sources/libo-core/external/firebird/firebird-cygwin-msvc.patch.1


C:/sources/libo-core/solenv/gbuild/UnpackedTarball.mk:166: recipe for target 'C:/sources/libo-core/workdir/UnpackedTarball/firebird.done' failed

Using Lazarus IDE with Firebird in Ubuntu and Debian

Install the ide

sudo apt-get install lazarus-ide

Start the ide from the console/terminal

 lazarus-ide &

If everything went well you'll see a new tab called SQLdb. This tab will contain two components a TSQLConnection and a TSQLQuery.








SQLdb tab also contains a component TIBConnection that you can place it on the form


We will connect to /var/lib/firebird/2.5/data/employee.fdb
On the form put an TIBConnection, TSQLTransaction,TSQLQuery,TDatasource and an TDBGrid









TIBConnection is configured to have DatabaseName=/var/lib/firebird/2.5/data/employee.fdb
Password=masterkey
Username=sysdba
and Transaction=SQLTransaction1
You can put it to be Connected = True




Then configure SQLTransaction1
to use

Database=IBConnection1
Active =True;




Configure TSQLQuery this way

Database:IBConnection1
SQL=select * from employee;
Active = True;








Configure TDatasource
DataSet=SQLQuery1



Configure TDBGrid

DataSource = DataSource1




Next you can put an button and make them active from run time


procedure TForm1.Button1Click(Sender: TObject);
begin
SQLQuery1.Active:=true;
end;

Fixes to fbexport compilation on linux systems debian/ubuntu

It's easy to compile firebird export utility just download the version from sourceforge

cd fbexport-1.90
after that modify fbcopy/TableDependency.cpp
and add

#include <stdio.h>

to the include section otherwise you will get the error error: ‘printf’ was not declared in this scope
make should complete the job (of course you need the firebird headers , check if you have them installed with dpkg -L firebird2.5-dev)

 make
g++ -c -O1 -DIBPP_LINUX -DIBPP_GCC -Iibpp -o fbcopy/args.o fbcopy/args.cpp
g++ -c -O1 -DIBPP_LINUX -DIBPP_GCC -Iibpp -o fbcopy/fbcopy.o fbcopy/fbcopy.cpp
g++ -c -O1 -DIBPP_LINUX -DIBPP_GCC -Iibpp -o fbcopy/TableDependency.o fbcopy/TableDependency.cpp
g++ -c -O1 -DIBPP_LINUX -DIBPP_GCC -Iibpp -o fbcopy/main.o fbcopy/main.cpp
g++ -c -O1 -DIBPP_LINUX -DIBPP_GCC -Iibpp -o ibpp/all_in_one.o ibpp/all_in_one.cpp
g++ -pthread -lfbclient ibpp/all_in_one.o fbcopy/args.o fbcopy/fbcopy.o fbcopy/TableDependency.o fbcopy/main.o  -oexe/fbcopy
g++ -c -O1 -DIBPP_LINUX -DIBPP_GCC -Iibpp -o fbexport/ParseArgs.o fbexport/ParseArgs.cpp
g++ -c -O1 -DIBPP_LINUX -DIBPP_GCC -Iibpp -o fbexport/FBExport.o fbexport/FBExport.cpp
g++ -c -O1 -DIBPP_LINUX -DIBPP_GCC -Iibpp -o fbexport/cli-main.o fbexport/cli-main.cpp
g++ -pthread -lfbclient ibpp/all_in_one.o fbexport/ParseArgs.o fbexport/FBExport.o fbexport/cli-main.o -oexe/fbexport

and the binary is in exe dir

exe/fbexport
--------------------------------
FBExport v1.80 by Milan Babuskov (mbabuskov), using IBPP 2.5.3.0
Tool for importing/exporting data with Firebird and InterBase databases.
Usage: fbexport -[S|Sc|Si|Sh|I|If|X|L] Options

 -S  Select = output to file  (S - binary, Si - INSERTs, Sc - CSV, Sh - HTML)
 -I  Insert = input from file
 -If Insert by Full SQL = input from file, by parameterized SQL
 -X  eXecute SQL statement, use with -F to execute sql scripts
 -L  List connected users

Options are:                           -H Host          [LOCALHOST]
 -D Database                           -U Username      [SYSDBA]
 -F Filename (use - for stdout)        -O Role
 -P Password                           -T Trim chars    [off]
 -A "Charset"                          -J "Date format" [D.M.Y]
 -Q "SQL Query statement"              -K "Time format" [H:M:S]
 -C # = Checkpoint at # rows [1000]    -M Commit at each checkpoint [off]
 -E # = Ignore up to # errors [0] Set to -1 to ignore all
 -R Rollback transaction if any errors occur while importing [off]
 -V Table = Verbatim copy of table (use -Q to set where clause if desired)
 -B Separator [,] = Field separator for CSV export. Allows special value: TAB
Command-line options are not case-sensitive (except the TAB setting)

Update

I have added a few more fixes in this fork on the github (related to linking errors) and included the compiling fixes from above 

Where #Firebird is better than #postgresql features included

I wanted to mention so will not forget when i will write a more extensive paper

1.Firebird required 0 Administration and is simpler to use than Postgresql
(think of sqlite like easy of use with oracle/postgresql like features)
I always hated the vacuum and complex installations for postgresql and yes
simplicity is a feature

See the postgresql features that they don't want (Scroll down to bottom)

2.Firebird does have Embedded mode and is fully multi threaded in 2.5

So yes i can build a single Firebird so/dll and put it on Android, Meego for example
and there is no need for a SuperServer , SuperClassic for it I just deploy it on the target device

3.And yes Firebird is fully multithreaded where Postgresql is NOT

so we are ahead in this area with at least 2 or more years

"All backends running as threads in a single process (not wanted)
This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years."

#MySQL price hikes reveal depth of #Oracle 's wallet ,Time for #Firebird?

These emails promise "changes to MySQL's pricing and possibly pricing model soon," with a further stealth price increase in the form of removal of MySQL's Basic and Silver support options.

Here is the Oracle letter in its entirety:

http://www.theregister.co.uk/2010/10/08/oracle_jacking_up_mysql_prices/

Howto and tips :converting from #mysql to #firebirdsql Part 2

In the first part i have showed you a method using csv files but there is
a smarter way to migrate from mysql or mssql , get the column info :name,type,pks http://www.php.net/manual/en/function.mysql-fetch-field.php
after that for each table we can create the table in firebird
1. get tables,get tables columns , types relations from mysql , or mssql (for that i will do an article later)
2. for each table, column create new tables with columns in firebird
3. for each row in each table select from mysql,mssql and insert in corresponding table in firebird
in a similar way we did in previous example but there i have inserted from csv
http://gist.github.com/589903
for mssql i will write another script for info , there is one sp that gives you just that
and we can use one query to get it

Here is the first sub step get all the columns info for one table

Howto and tips :converting from #mysql to #firebirdsql

here are some basic types to be converted from mysql to firebirdsql when you run the create table scripts

• int(10)->int
• smallint(5)->int
• datetime->timestamp
• replace the ` with double quote " or with nothing

dump the database with full inserts and then run it with flamerobin
mysqldump  -u root --password=mysql_password -t -c dbname tablename > /tmp/foo.sql

another option is to put dump table in csv format and import it using a php script
that fetches each row and inserts it into firebird table
here is one example for a table with 3 columns



or search for a tool that will do that for you

something is wrong with #mssql tpch submission

It seems to me they have submitted the mssql ent version for one cla (one user) and that means one app will use that server ! now that is cheap because is useless .Why don't they put something like ent edition licesed on x2 cpus ?
also the price for the windows os induces some handicaps , compare that with free as in freedom linux (debian)

did you knew that mssql server 2008 is limited to 8 cpus ! compare that with firebird where is unlimited
also the limit in r2 is 256 , in firebird  you have a no limit again and you can use it on a 2048 cpus type server if you want or more if sgi allows us to test it on that server :

with architectural support to 262,144 cores (32,768 sockets).

Life is good after #Oracle , see you in 10 years

OpenSolaris is dead kudos to Linux type fundations like debian , fedora ...(see the distrowatch to see the enemies of Solaris)
MySQL is dead kudos to the Firebird and Postgresql real open source fundations. No one that sane will ever touch mysql source code that will come from oracle . See the java patent patern from bellow.
Java is dead and replaced by native and scripting languages , I see google opening the native code floodgates
and maybe entering meego fundation and this way who knows in the future we will see a QT based  android
There is is already a port of QT to android called android lighthouse
http://code.google.com/p/android-lighthouse/
and read the Qt on Android - the Bogdan Vatra interview

And you can watch some really interesting demos for qt on android , it really works well
http://taipan.blip.tv/

LightHouse is a project to make porting Qt easy. Essentially, you just need to create a plugin which moves your content to the screen of the device. In my case, I did that and ported the shared memory concept and semaphore model -> done.

with better speed :C++ is always faster than any interpreted code (You read this with an C++ browser and NOT with a java based one). And already i see they push the scripting languages like python and ruby and php and javascript . You can build a real apk now with full power of scripting languges inside. May the lua force be with you .Mono is nice but there is another enemy at the gates: Microsoft and they do have a lot of patents on their war chest

Also community reacts and people leave the oracle's open source projects

I can't continue to contribute to a project sponsored by a company that use an Open Source language to monetize the patents portfolio they got from the acquisition of another company. I will feel like I'm paying money to SCO to have the right to use Linux... Yeah, I'll feel that bad.
So, I choose to leave the team instead of going against my convictions.

Take a look at the map yes Firebird and Postgres is fighting a strong war against Microsoft and Oracle (there are Billions there in the middle )

Map should be updated with mysql code split inside of the oracle and some of it outside somewhere in the ubuntu's launchpad

Interesting that the browser war is a lost cause for microsoft , you can't do anything against webkit period
and to add salt to the injury you can't do anything against firefox
The same with open source databases you can't do anything against them it's lost war
Ahh and by the way SCO is dead , nginx is getting web market share and the army of IPhones and Androids
killed everything microsoft had put on the table in the mobile area : Do you want a Kin anyone
I'm wet after Android and nokia but i will never use a Windows based mobile phone .

http://www.theinquirer.net/inquirer/news/1602970/microsoft-won-t-dominating-os


Gartner's study shows Android to be the fastest growing mobile smartphone operating system (OS) in the second quarter .Android overtook Apple’s iPhone OS to become the third-most-popular OS in the world  As has been confirmed by several other reports, the Linux-based Android overtook RIM’s BlackBerry OS to become the top selling smartphone OS in the U.S.,

http://www.linuxfordevices.com/c/a/News/Gartner-2Q-report-and-AndroidLinux-fork/

Installing jaws #php #cms on #ubuntu lucid and #firebird backend

This is tutorial on how to install  jaws-cms on ubuntu and with firebird 2.1 backend

cd /var/www
sudo wget http://bits.jaws-project.com/releases/jaws-0.8.13/jaws-complete-0.8.13.tar.gz
sudo tar -zxvf jaws-complete-0.8.13.tar.gz
sudo mv html jaws

sudo chmod -R g+rw jaws
sudo chown -R www-data.www-data jaws

create an new database with flamerobin /var/lib/firebird/2.1/data/jaws.fdb

create a symlink , seems that if you put only jaws.fdb in the database field
then it needs to be located in jaws/data

cd /var/www/jaws/data
ln -s  /var/lib/firebird/2.1/data/jaws.fdb

start the installer http://localhost/jaws/install/
fill in the username for database and password
at database put jaws.fdb
Some screenshots created during the install process

All requirements are OK check the green results field
Also for php gd i had to install it this way

sudo apt-get install php5-gd

and for firebird php driver
check if is installed with

sudo apt-get install php5-interbase

and then restart the apache server so that php driver to be really loaded after install

sudo /etc/init.d/apache2 restart

and here is the administration area that you can access with
http://localhost/jaws/admin

If you play with the gadgets and add them to the Layout area in a few seconds you have a blog, rss feed (i have added firebirdnews rss feed) and visitor count and then a search box
So a community style of site can be created in a few steps and it's very easy to start it

extracting date from an timestamp value in firebird

you can use the cast to extract the date from timestamp

SELECT cast('now' as date)
FROM rdb$database

in my case the result is

28.07.2009

someone asked on webhostingtalk how to do it

also you can extract only the year or month using the extract function

building qt4.5 on jaunty

$ dget -x http://ftp.de.debian.org/debian/pool/main/q/qt4-x11/qt4-x11_4.5.0~rc1-2.dsc

$ cd qt4-x11-4.5.0~rc1/

$ debuild -i

I was missing some packages (check what you need on your system)

$ sudo apt-get install cdbs libcups2-dev libdbus-1-dev libiodbc2-dev libmng-dev libpam0g-dev libreadline5-dev libsqlite0-dev libtiff4-dev libxmu-dev libxslt1-dev libphonon-dev

$ debuild -i

$ ls -1 *.deb

libqt4-assistant_4.5.0~rc1-2_i386.deb

libqt4-core_4.5.0~rc1-2_i386.deb

libqt4-dbg_4.5.0~rc1-2_i386.deb

libqt4-dbus_4.5.0~rc1-2_i386.deb

libqt4-designer_4.5.0~rc1-2_i386.deb

libqt4-dev_4.5.0~rc1-2_i386.deb

libqt4-gui_4.5.0~rc1-2_i386.deb

libqt4-help_4.5.0~rc1-2_i386.deb

libqt4-network_4.5.0~rc1-2_i386.deb

libqt4-opengl_4.5.0~rc1-2_i386.deb

libqt4-opengl-dev_4.5.0~rc1-2_i386.deb

libqt4-qt3support_4.5.0~rc1-2_i386.deb

libqt4-script_4.5.0~rc1-2_i386.deb

libqt4-scripttools_4.5.0~rc1-2_i386.deb

libqt4-sql_4.5.0~rc1-2_i386.deb

libqt4-sql-ibase_4.5.0~rc1-2_i386.deb

libqt4-sql-mysql_4.5.0~rc1-2_i386.deb

libqt4-sql-odbc_4.5.0~rc1-2_i386.deb

libqt4-sql-psql_4.5.0~rc1-2_i386.deb

libqt4-sql-sqlite2_4.5.0~rc1-2_i386.deb

libqt4-sql-sqlite_4.5.0~rc1-2_i386.deb

libqt4-svg_4.5.0~rc1-2_i386.deb

libqt4-test_4.5.0~rc1-2_i386.deb

libqt4-webkit_4.5.0~rc1-2_i386.deb

libqt4-webkit-dbg_4.5.0~rc1-2_i386.deb

libqt4-xml_4.5.0~rc1-2_i386.deb

libqt4-xmlpatterns_4.5.0~rc1-2_i386.deb

libqt4-xmlpatterns-dbg_4.5.0~rc1-2_i386.deb

libqtcore4_4.5.0~rc1-2_i386.deb

libqtgui4_4.5.0~rc1-2_i386.deb

qt4-demos_4.5.0~rc1-2_i386.deb

qt4-designer_4.5.0~rc1-2_i386.deb

qt4-dev-tools_4.5.0~rc1-2_i386.deb

qt4-doc_4.5.0~rc1-2_all.deb

qt4-doc-html_4.5.0~rc1-2_all.deb

qt4-qmake_4.5.0~rc1-2_i386.deb

qt4-qtconfig_4.5.0~rc1-2_i386.deb

now i have the webkit for building arora and ibase library to access firebird

Installing jaws php cms on ubuntu and firebird backend

Installing jaws-cms on ubuntu and firebird backend

$ cd /var/www
$ wget http://bits.jaws-project.com/releases/jaws-0.8.6/jaws-complete-0.8.6.tar.gz
$ tar -zxvf jaws-complete-0.8.6.tar.gz
$ mv html jaws

sudo chmod -R g+rw jaws
sudo chown -R www-data.www-data jaws

create an new database with flamerobin /var/lib/firebird/2.1/data/jaws.fdb

crate a symlink , seems that if you put only jaws.fdb in the database field
then it needs to be located in jaws/data

$ cd /var/www/jaws/data
$ ln -s /var/lib/firebird/2.1/data/jaws.fdb

start the installer http://localhost/jaws/install/
fill in the username for database and password
at database put jaws.fdb

Some screen shots o took during install and configuration

compiling pdo support in php - needed for phpmyfaq

or compiling php 5.2.x with pdo support all i did at configuration time is like adding
--with-pdo-firebird=/opt/firebird switch
then make; make install
Check the phpinfo() and pdo_firebird was there



cat config.nice

Code:

#! /bin/sh
#
# Created by configure

'./configure' \
'--with-apxs2=/opt/apache2.2/bin/apxs' \
'--prefix=/opt/php5.1' \
'--with-xml=shared' \
'--with-pdo-mysql=/opt/mysql-5.0.18/' \
'--with-pdo-firebird=/opt/firebird' \
"$@"

then download phpmyfaq

In my case 2.5.0 but the same apply to 2.0.8

http://www.phpmyfaq.de/download.php?do=download&number=2.5.0-alpha&ext=.tar.gz
unzip-it
tar -zxvf phpmyfaq-2.5.0-alpha.tar.gz
chown www-data.www-data phpmyfaq-2.5.0-alpha
chmod -R g+rw phpmyfaq-2.5.0-alpha
mv phpmyfaq-2.5.0-alpha phpmyfaq

and run the installer

http://localhost/phpmyfaq