mariuz, Author at Firebird News

CakePHP RC3 – The RC of Triumph!

October 9, 2008 mariuz Leave a comment

It’s finally here: the final release before the final release of
CakePHP 1.2 [ED:Tested and works just fine with Firebird 2.1]

Some of you may remember the benchmarks posted by Rasmus Lerdorf, in
which CakePHP did not perform so well. We can all debate Rasmus’ due
diligence (or lack of), but what was clear was that we had some
catching up to do. Over the past few weeks, Larry has worked
tirelessly on iteration after iteration of performance improvements,
and now we’re faster than ever before. By itself, the bootstrap
process is over 10x faster than RC2, and basic requests for static
content are now about 5x faster overall.

Patch for DotNet Provider 1.7 to connect against Firebird 2.1

October 9, 2008 mariuz Leave a comment

Attached is a patch file ( a ZIP file with extension changed , you should rename it from piz to zip ) with
changes to allow v1.7 of the provider to connect against Firebird 2.1,
changes has been done by backporting 2.5 svn sources to the v1.7 sources.

[ED: soon there will be an v1.7 release that will integrate this patch]

Firebird Developers’ Day 2008 – Czech Republic

October 9, 2008 mariuz Leave a comment

As we have already informed you, we organize the 16th
October together with x2develop.com second annual training conference on the Firebird database platform.

Conference Firebird Developers’ Day 2008 will take place 16th
October 2008 at Prague’s Charles University Faculty of Science, Albertov 6, in the hall known as the Tower. K

Fixed bugs in php – crash on query with errors in params

October 8, 2008 mariuz Leave a comment

Thanks to Felipe Pena for fixing many php bugs related to firebird extension . This is an example how bug has been fixed in CVS.
http://bugs.php.net/bug.php?id=45373

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

[See remaining text…]

Firebird-Python and Character set issues – From Bug/Post of the day dept

October 7, 2008 mariuz Leave a comment

After a long interruption I’m back at Firebird and kinterbasdb and I’m
just also back at character set troubles, my favorite pastim

[See remaining text…]

My test setup is WinXP, Firebird 1.5.5, Python 2.5.2 and kinterbasdb
3.3pre (20070503).

I’m initializing kinterbasdb with type_conv = 200, which is the only
sensible choice in this setup, if I’m not mistaken.

Now, after some tests, I’d like to share some observations and
suggestions. I’ll start with the sane ones and will hold back with the
not so sane ones until another posting.

== CHARACTER SET ASCII isn’t handled correctly ==

kinterbasdb will not accept Unicode input for ASCII database fields,
despite the fact that the operation isn’t less well defined as the
conversion to any other character set.

It’s correct to fail on Unicode to NONE and Unicode to OCTETS
conversions, as they are illdefined. But this argument doesn’t apply
to ASCII. And with Unicode the default string type in future Python
versions, IMHO a change is needed.

== The connection character set is ignored ==

kinterbasdb is willing to set a connection character set, but it will
ignore it for its own transcoding!

This implies, that only connection character set NONE or a connection
character set equal to (or being a superset of) all column character
sets will work.

In all other cases, character set transcoding by Firebird will occur
without being taken into account by kinterbasdb.

Perhaps an example makes this more explicit:

* Column character set is ISO8859_1
* Connection character set is set to DOS850

The sequence of events:
(1) Python wants to store a string consisting of a single character
U+00F6 (small o-umlaut).
(2) kinterbasdb matches ISO8859_1 (the column character set) to
Pythons character set of the same name (and fortunately same
semantics) and calls unicodeString.encode(

pyEncodingName). This will
result in an 8-bit string holding a single byte of 0xF6
(3) Firebird, believing in the specified connection character set
DOS850, transcodes this to an intermediate Unicode representation,
yielding U+00F7 (division sign) and then to the column character set,
resulting in 0xF7 being stored.

Perversely, when reading from the database by the same setup, no
problem will be seen (in this case) as the faulty sequence of
transcodings will occur in reverse and the damage is undone (but IMHO
this only makes it worse).

Regards,
Peter

« Hide it