hi Lester, On Sun, Jun 15, 2008 at 6:22 PM, Lester Caine <[EMAIL PROTECTED]> wrote:
>> Not easy to fix issues yourself but you are getting amazingly more >> involved, this step is more than welcome! > > I've always been monitoring and testing - but my main activity is USING in a > number of other projects ;) That means you know it and how it works with php, that's what we need now :) >> In the meantime I tried to build the 2.1.x releases (1.x dsw/dsp do >> not even want to be opened by vc6). It seems to work well but I met a >> couple of issues due to the wrong architecture detection (it uses the >> processor I use instead of actually using the current configartion, >> you can compile for x86 on x64 or cross compile for x64 on x86). >> Patches on their way, I suppose I can send them to firebird-developer? > > http://tracker.firebirdsql.org/ Ah right, the tracker. Thanks for the link >> By the way, do you know if the 2.1 lib is 100% BC compatible with the >> 1.x serie? If yes, I can then use them for the php windows binaries. > > The 2.1 client should access data from any older version of the server. > Certainly I have no problems with FB1 running on W98SE ( Yes we still have > to support that :( ) or 1.5 on Linux or Windows and I was still running > IB5.6 until recently without a problem. I will use with 2.1 for 5.3+ and keep using what we have now for 5.2.x. That will be a good test for the new lib. > There was talk about dropping the .zip because the 'installer' was > available. Hopefully that idea has died on the vine. There is no plan to drop the zip releases. >>> http://fbexport.sourceforge.net/ibtest.php.txt is our base set of tests >>> and >>> this shows a problem with NUMERIC(18,7) and above so we avoid that. >>> >>> The problem is fixing the problems we find? >> >> Can you elaborate please? Or is there a bug # in bugs.php.net? > > Fixed - http://bugs.php.net/bug.php?id=39700 > but I try and avoid snapshots so I can't test yet. > 42266 is the remaining niggle that is assigned to abies and the only one of > the other bugs open needs checking to see what that problem is (43674) Any chance to turn the ibtest.php.txt scripts into a set of phpt files? It can then be used as main tests for php (make test or with run-tests.php). I can give try to fix it and use the tests to valid my changes. > Interbase is not dead! As soon as the Inprise/Borland accountants realised > what they had done in trying to end of life it they tried to closed the door > again. http://www.codegear.com/products/interbase - rather costly especially > when Firebird is available free. Oh, I thought it was not maintained anymore. > Not sure that there is anything new to be done. > Main thing I think is transparent unicode. Firebird has always supported > different collations/codesets per field in a table so has not had the > restriction of other databases - which only supported a single codeset per > database. Making everything UTF8 just simplifies everything in one hit and > wipes out the need to manage code tables on a field by field basis :( I > think that is one of the things that PDO would not allow, but it's been a > while since I looked. That could be possible without unicode if mbstring is available (for the end users to decode the return value). Unicode support and conversion abilities obviously help a lot more. Can you describe the needs in the wiki please? And maybe what would be nice to add? That will be useful for anyone willing to contribute and looking for some todos. >> I can provide the libs in the next days as well as use them in our >> binaries snapshops (5.3, 6.x, maybe 5.2 if it works well and is 100% >> BC). > > Static linking the client library may be a problem! Flamerobin needs to use > the client for database management, and my legacy applications run in > parallel on some machines. I run multiple web servers each with their own > local legacy hardware but sharing data on a remote server. Ah right, we do it dynamically already (was looking for fbclient but we still use gd32.dll :). -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
