Firebird 2.5.2 svn snapshot 53775 landed in Debian unstable

firebird2.5 (2.5.2~svn+53775.ds4-1) package is now in debian unstable
Here is the list of debian changes and fixes

* Snapshot from upstream’s 2.5 branch, revision 53775
* control: note -doc doesn’t contain release notes (LP#908963)
* control: change transitional 2.5-dev package to oldlibs/extra
* control: -common package is arch:all
the last arch-specific bit, ibutil was moved to -server-common
* -classic.init: provide a status option
* control: 2.5-dev, -classic-common: depend on the same (source) version of
-common-doc

Firebird SQL Project Newsletter, Issue 2

Yesterday the second issue of Firebird SQL Project newsletter was delivered to all subscribers. This issue includes announcements of official Firebird channels at YouTube and SlideShare, the full list of materials from Firebird Conference 2011, and also digest of recent community news.
You can read the second issue online.

We strongly encourage you to subscribe to Firebird SQL project newsletter in order to receive new issues in time.

Status of PHP PDO_Firebird as of December 2011

If you have read the previous article about Firebird pdo status then you might now that almost all worked  except binding parameters by name (see  bug #48877).

But as a gift bug #48877 is fixed in svn , and is already in the php  snapshots for 5.4.x,5.3.x and trunk 5.5.x

So it should all work from the mentioned article , There are still some bugs left but it will be fixed until the end of the year : Bugs #47415 and #53280 are already done from my todo list


Help testing TcpRemoteBufferSize parameter

The parameter TcpRemoteBufferSize found in firebird.conf is supposed to set the maximum size of a packet being transfered. The default value for Firebird is 8K, and the maximum accepted is 32767. Theoretically, bigger packets should make the transfer of large resultsets faster (mostly noticed when connection is high latency networks, aka internet).

Recently, I did some tests with this parameter, but wasn’t able to find any differences in the time of a fetchall with a select first 2000 * from some_table_with_no_blobs_and_lots_of_records. A similar test that I did last year, with different FB version and O.S. showed a speed increase of almost 3x in the fetchall time when the packet size was set to 32K, but seems that I cannot reproduce this with my current environment anymore.

If you have some time, please do some tests with this parameter, and publish the results in the comments of this post. Remember to test changing the value at client, at server, and at both, and to mention what Firebird version was used (at server, and client library too, if different). Also, I recommend to run the first select/fetchall at last one time before getting the results, to fill Firebird and O.S. cache and get more accurate results.

If you are a “hardcore” user, you may also want to install Wireshark and have an inside view of the communication process.

1 116 117 118 119 120 200