Category: General news

The option in the config is removed

 

Prior to Firebird 2.5 the SET clause of the UPDATE statement assigned columns in the user-defined order with the NEW column values being immediately accessible to the subsequent assignments. This did not conform to the SQL standard. Starting with Firebird 2.5, only OLD column values are accessible to all the assignments of the SET clause.

Example of the old vs new behaviour:

UPDATE T SET A = B, B = A

old result: A gets equal to B, B doesn’t change

new result: A and B get their values exchanged

Change this configuration option to 1 (true) only if your SQL code relies on the legacy semantics of the SET clause. It’s provided as a temporary solution for backward compatibility issues and is removed in Firebird 3.0
Type: boolean

OldSetClauseSemantics = 0

Posted in FB-DEVEL:

FIrebird for Android
——————–

Key: CORE-3885
URL: http://tracker.firebirdsql.org/browse/CORE-3885
Project: Firebird Core
Issue Type: Task
Components: Build Issues / Porting
Affects Versions: 2.1.5
Environment: Android 4
Reporter: JLM
Priority: Minor

Hello,

I’m trying to build Firebird 2.1 for Android ARM.
For the moment, I am compiling, step by step, by correcting builds issues.
To compile, I use the custom NDK R7 by Crystax in order to use the standard libc instead of the Bionic libc.

I will write my advance gradually.

Regards,
Loweno

Do you have interest? Vote for it in the tracker and show your support  😉

Highlights for this release:

• – Support for Firebird stream BLOBs (see ReleaseNotes for details)
• – Fix for PYFB-17 and PYFB-18 (see our JIRA tracker for details)
• – Fixes for automatic unicode conversions + refactoring
• – Some optimizations
• – Documentation (stub, from KInterbasDB 3.3.0)

Target for next release: Documentation

After searching the internet for a decent walk through or tutorial, I came up with very little and so I decided to collate what have learned in this post with the hope that someone else can benefit from it.

Firstly you will need to obtain the datasources plugin from github and stick it in your application’s plugin folder (app/plugins) – make sure you get the master branch and not the 2.0 as it needs to be compatible with your version of CakePHP (1.3 ideally)

The next thing you need to do is edit the databases config file (app/config/database.php):

var $default= array(

        'driver' => 'Datasources.DboFirebird', //references the datasources plugin

        'persistent' => false,

        'host' => 'localhost', //the host name of your database

        'login' => 'sysdba',

        'password' => 'masterkey',

        'database' => 'C:\\path\\to\\database.gdb', //path to the database - note the double backslashes

        'prefix' => '',

        //'encoding' => 'utf8',

    );

The two important things you should note of is the driver key-value pair which references the datasource plugin namespace, and secondly the double backslashes for the database file path.

All the models you create for your application should now access the corresponding tables through the FireBird SQL connection.

Here is the first commit with the nice message :

Cross-build support + android port: work in progress, currently can build fbclient for android

Here is the Firebird bug fixed : #CORE-2666
Today you can use the API remotely to create a serverside backup. You can use GBAK to create a remote backup (e.g. via Internet). And Today you can use API to create remote backup, i.e. create a backup serverside and flush it to the client.

Here is the documentation from the doc/README.services_extension

4) Services API extension – running gbak at server side with .fbk at the client.
(Alex Peshkov, 2011-2012)

This way of doing backups is specially efficient when one needs to perform
backup/restore operation for database, located on ther server accessed using
internet, due to serious performance increase.

The simplest way to use this feature is fbsvcmgr. To backup database run
approximately the following:
fbsvcmgr remotehost:service_mgr -user sysdba -password XXX \
action_backup -dbname some.fdb -bkp_file stdout >some.fbk

and to restore it:
fbsvcmgr remotehost:service_mgr -user sysdba -password XXX \
action_restore -dbname some.fdb -bkp_file stdin <some.fbk

Please notice – you can't use "verbose" switch when performing backup because
data channel from server to client is used to deliver blocks of fbk files. You
will get appropriate error message if you try to do it. When restoring database
verbose mode may be used without limitations.

If you want to perform backup/restore from your own program, you should use
services API for it. Backup is very simple – just pass "stdout" as backup file
name to server and use isc_info_svc_to_eof in isc_service_query() call. Data,
returned by repeating calls to isc_service_query() (certainly with
isc_info_svc_to_eof tag) is a stream, representing image of backup file. Restore
is a bit more tricky. Client sends new spb parameter isc_info_svc_stdin to server
in isc_service_query(). If service needs some data in stdin, it returns
isc_info_svc_stdin in query results, followed by 4-bytes value – number of bytes
server is ready to accept from client. (0 value means no more data is needed right
now.) The main trick is that client should NOT send more data than requested by
server – this causes an error "Size of data is more than requested". The data is
sent in next isc_service_query() call in the send_items block, using
isc_info_svc_line tag in tradition form: isc_info_svc_line, 2 bytes length, data.
When server needs next portion, it once more returns non-zero isc_info_svc_stdin
value from isc_service_query().

A sample of how services API should be used for remote backup and restore can be
found in source code of fbsvcmgr.