From Pierre
Playing off base. What I proposed you is to help us to get your
software continue to run smoothly with PHP, while keeping the windows
support. In the end you may even get a faster version on windows, but
I suppose you don't care about that (poor customers ;) .
This I think is part of the current battle - and it is a battle - between
those of us who use and spend a lot of our time SUPPORTING PHP use in the field.
I came to PHP when PHP5 was in late beta, with RC's just coming out, and I
actually release my first applications in early 2004 USING a late RC for the
simple fact that I THOUGHT at the time it was going to be the way forward. I
knew there was still a 'problem' with Unicode in PHP5 but the discussion even
then was that this would be addressed in PHP6 - something that was then nailed
down at that meeting in Paris in November 2005?
Did I make the right choice going to PHP5 early? Well in hindsight probably
not, because on the projects that I contribute to I have been - in my mind -
wasting time fixing problems introduced by 'improvements' to PHP4 ever since.
Since most USERS have never been convinced of the advantages of PHP5, until
the plug was finally pulled on PHP4. I wish that PHP4 had been put into a
security fixes only mode a year or so earlier, so we could have nailed down
applications that work with the final release and got on to actually USING the
improvements in PHP5 in the field. OK some projects who had a lot more
developers split their projects and started PHP4 and PHP5 versions, but I
obviously back the wrong horses :( Perhaps Interbase/Firebird is the same
wrong decision, but I've been using that since the early 90's - long before
web based working became the norm.
Do my CUSTOMERS need a new tidied version of Array - NO - they have no idea
what goes on under the cover. They all have a job to do and in many cases THAT
has not changed in the last 20 years. Yes HOW they do it has changed, but
essentially things like 'write a letter' are not using anything that was not
available and perfectly functional 20 years ago. They have gained nothing by
the cost of several upgrades to windows. In fact NOW they may not even be
using a word processor at all, with simple form letters generated in web based
applications. The very applications PHP is providing so nicely.
None of my paying customers actually need Unicode, simple Ascii English is
fine for them. The main reason I 'would like' to get away from the mess of
code tables and character conversions is for the non-paying people who use the
international projects that I help to develop. I have spent a lot of time
making those projects compatible with all of the problems that changes to PHP4
and 5 have thrown at me and now I'd like to pin down a build of PHP5 that I
can consider stable, get into security only mode, and get on to a version of
PHP that is a simple flat field for multi-lingual text.
Am I letting my customers down - NO - we are developing a number of
enhancements to what they DO with their systems, while battling to fix the
problems of 'improvements' to OS, Browsers, and even the Database engine. Yes,
this compulsive requirement to keep changing things is even causing problems
in the Firebird camp!
Can I simply bury my head in the sand and ignore the newer versions of PHP5.3
- NO - because users of the projects I'm involved with will be complaining
that something does not work. Heck we are getting bug reports for PHP6 !!!
To me open source is about cooperation. We all contribute what we can to the
melting pot. Personally I spent two years as treasurer of the Firebird
Foundation and only stepped down because a change in workload :( Windows does
not make for an 'open' development process although I do understand that the
major block of having to BUY a M$ compiler has been removed? If I had my way,
I would only support Linux servers, and some of my 'windows only' customers
are now ASKING for Linux when we need to upgrade server hardware!
Do I have time to help develop PHP on Windows - NO. Would I find time if key
parts are dropped - probably not. I had to find time when Borland announced
that Interbase was being killed off in 1998. I had ten years of time invested
in the products using it. I learnt one lesson, and 95% of what I am now doing
is not dependant on product that someone else can wipe out. The current
problem is the 5% that is and that code base is over 15 years old! It still
does what the customers want perfectly so they are unwilling to change it, and
I don't have time to do more than recompile things every time windows moves
the goal posts.
CURRENTLY - what is actually WRONG in PHP5?
Look at the minutes of the 'PHP6' meeting
http://www.php.net/~derick/meeting-notes.html - what has actually been
addressed in coming up to 3 years?
Can we answer point 1.1 yet - is the current logjam brought about by requiring
an OFF switch - if PHP6 is unicode only internally can we move it forward, and
keep PHP5 as the none unicode branch?
Can't we learn from the 'mistakes' of PHP4 or are we still going to be waiting
for PHP6 in another 3 years.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
<snip>From Pierre
Playing off base. What I proposed you is to help us to get your
software continue to run smoothly with PHP, while keeping the windows
support. In the end you may even get a faster version on windows, but
I suppose you don't care about that (poor customers ;) .This I think is part of the current battle - and it is a battle -
between those of us who use and spend a lot of our time SUPPORTING
PHP use in the field.
I hope the purpose if this post was to vent .. and I hope that you are
now vented. Aside from this you just wasted the time of anyone who has
actually read your post, hoping that there would actually be some
relevant content to read. Instead you can shouted, which several
people have asked you not to do. Lester next time you are about to
click "send" on a mail where you have capitalized entire words, please
take a deep breather and hit deleted instead.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
PS: How about instead sending a mail to the firebird foundation, to
which you seem well conntected, and see if they can help?
Lukas Kahwe Smith wrote:
<snip>From Pierre
Playing off base. What I proposed you is to help us to get your
software continue to run smoothly with PHP, while keeping the windows
support. In the end you may even get a faster version on windows, but
I suppose you don't care about that (poor customers ;) .This I think is part of the current battle - and it is a battle -
between those of us who use and spend a lot of our time SUPPORTING PHP
use in the field.I hope the purpose if this post was to vent .. and I hope that you are
now vented. Aside from this you just wasted the time of anyone who has
actually read your post, hoping that there would actually be some
relevant content to read. Instead you can shouted, which several people
have asked you not to do. Lester next time you are about to click "send"
on a mail where you have capitalized entire words, please take a deep
breather and hit deleted instead.
Partly to vent - see other post about finfo_open - this weekends waste of
time! "It works fine here" from other developers is equally annoying when
looking at a white screen without even an error message!
But the main problem is getting some answers to what is happening to PHP6. I
will continue to shout now since asking politely over the last couple of years
has not achieved anything :(
regards,
Lukas Kahwe Smith
mls@pooteeweet.orgPS: How about instead sending a mail to the firebird foundation, to
which you seem well conntected, and see if they can help?
They have had the discussion and since the php_interbase driver IS working
fine with Firebird since Ard produced the PHP5 version of it then there has
been no requirement to replace Ard's effort. None of the people actively using
Firebird on PHP can see the need to invest any time in PDO but because of the
bugs introduced in the 64 bit linux builds of php_interbase we are trying to
get some time invested into that. The core development work in FB has been
unicode, and any work on the driver for PHP6 is stalled until there is
something that can actually be done :(
Two years ago I had a fully configured development setup for PHP6 on linux all
ready to get stuck in. Since then I've lost a major source of funding and
fixing some of the stupid little problems due to PHP upgrades is now an
irritating delay to other more productive work. It normally takes hours to get
into other peoples code to find out where the fault is even before you can
start to find a fix! Having then to learn the insides out of the whole of the
PHP code base to fix the actual bug is just impractical - and half the time
the 'bug' is actually a pigging change to some functionality :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
They have had the discussion and since the php_interbase driver IS
working fine with Firebird since Ard produced the PHP5 version of it
then there has been no requirement to replace Ard's effort. None of
the people actively using Firebird on PHP can see the need to invest
any time in PDO but because of the bugs introduced in the 64 bit
linux builds of php_interbase we are trying to get some time
invested into that. The core development work in FB has been
unicode, and any work on the driver for PHP6 is stalled until there
is something that can actually be done :(
Ok, to spell it out one last time: If windows support cannot be
provided in 5.3, there is a good chance that this will increase the
likelihood that interbase driver will soon be out of PHP core, even if
it still works on Linux. Also to remind you once again, our windows
guy has gone missing and we are rebuilding things from scratch for
5.3. If this is not enough of a problem to fix, then so be it.
If you continue to shout, then we have a good chance of being the
first (or among a very small group of people) to be banned from this
list. Though this is of course not my call to make.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
Ok, to spell it out one last time: If windows support cannot be provided
in 5.3, there is a good chance that this will increase the likelihood
that interbase driver will soon be out of PHP core, even if it still
works on Linux. Also to remind you once again, our windows guy has gone
missing and we are rebuilding things from scratch for 5.3. If this is
not enough of a problem to fix, then so be it.
I've obviously missed something ....
If there is a problem simply providing a windows build of PHP5.x then that is
a different matter.
Still not saying I can help - but I have already spent some time having
another look at doing my own Windows builds. It looks like the same problem I
have with my own Firebird builds though ... need M$ tools to do the job :(
I have an older windows server that is running as backup at present which I
could safely load some of the M$ stuff on - if it will work on W2k .....
But I'd prefer to stay inside my safety zone .....
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Lester Caine wrote:
Lukas Kahwe Smith wrote:
Ok, to spell it out one last time: If windows support cannot be
provided in 5.3, there is a good chance that this will increase the
likelihood that interbase driver will soon be out of PHP core, even if
it still works on Linux. Also to remind you once again, our windows
guy has gone missing and we are rebuilding things from scratch for
5.3. If this is not enough of a problem to fix, then so be it.I've obviously missed something ....
If there is a problem simply providing a windows build of PHP5.x then
that is a different matter.
Still not saying I can help - but I have already spent some time having
another look at doing my own Windows builds. It looks like the same
problem I have with my own Firebird builds though ... need M$ tools to
do the job :(I have an older windows server that is running as backup at present
which I could safely load some of the M$ stuff on - if it will work on
W2k .....
OK fell at first hurdle :(
Two notes on Windows Building from source page
1/ Links only work from IE Browser - or at least to get a download to start
2/ Express will only install on XP or Vista
Both XP machines here have Builder Development suites I can't risk damaging :(
But I'd prefer to stay inside my safety zone .....
Back to doing this on cygwin .....
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
hi Lester,
Lukas Kahwe Smith wrote:
Ok, to spell it out one last time: If windows support cannot be provided
in 5.3, there is a good chance that this will increase the likelihood that
interbase driver will soon be out of PHP core, even if it still works on
Linux. Also to remind you once again, our windows guy has gone missing and
we are rebuilding things from scratch for 5.3. If this is not enough of a
problem to fix, then so be it.I've obviously missed something ....
If there is a problem simply providing a windows build of PHP5.x then that
is a different matter.
Still not saying I can help - but I have already spent some time having
another look at doing my own Windows builds. It looks like the same problem
I have with my own Firebird builds though ... need M$ tools to do the job :(
What we actually need is not C developers or new core developers
(well, we do but it is not a requirement here). We are missing tests
(as in phpt which can be run using a firebird DB) and active users
giving feedback and running these tests.
If you can write tests (you and the PHP firebird community) and run
them using our sources and binary releases, that will already do the
job. That's all we need to keep the extension alive.
I have an older windows server that is running as backup at present which I
could safely load some of the M$ stuff on - if it will work on W2k .....
But I'd prefer to stay inside my safety zone .....
We can take care of the builds and port the firebird clients libraries
to Windows and/or MS tools. But we can do it only if we have a way to
test them :)
Cheers,
Pierre
Pierre Joye wrote:
hi Lester,
Lukas Kahwe Smith wrote:
Ok, to spell it out one last time: If windows support cannot be provided
in 5.3, there is a good chance that this will increase the likelihood that
interbase driver will soon be out of PHP core, even if it still works on
Linux. Also to remind you once again, our windows guy has gone missing and
we are rebuilding things from scratch for 5.3. If this is not enough of a
problem to fix, then so be it.
I've obviously missed something ....
If there is a problem simply providing a windows build of PHP5.x then that
is a different matter.
Still not saying I can help - but I have already spent some time having
another look at doing my own Windows builds. It looks like the same problem
I have with my own Firebird builds though ... need M$ tools to do the job :(What we actually need is not C developers or new core developers
(well, we do but it is not a requirement here). We are missing tests
(as in phpt which can be run using a firebird DB) and active users
giving feedback and running these tests.
Well when I originally reported the problems that were creeping into
php_interbase (linux and windows) I was told that I should fix them, and I
keep being told I should get involved more. So
http://lsces.co.uk/lsces/wiki/index.php?page=PHPDevelopment
Had the M$ express stuff installed on my backup W2k machine it would probably
not have been a problem, but I can't upgrade it since I need W2k on that
machine to test against ;)
I've been through the mill with M$ installs trashing the rest of my
development environment in the past, so I am not going to risk it again.
If you can write tests (you and the PHP firebird community) and run
them using our sources and binary releases, that will already do the
job. That's all we need to keep the extension alive.
Testing is not a problem ESPECIALLY while we can run multiple versions of PHP
on windows without the crap loaded into other applications which trash the
working version and overload it with a version which may not work. I DON'T go
with code that only has windows installers and would not test them ;)
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?
I have an older windows server that is running as backup at present which I
could safely load some of the M$ stuff on - if it will work on W2k .....
But I'd prefer to stay inside my safety zone .....We can take care of the builds and port the firebird clients libraries
to Windows and/or MS tools. But we can do it only if we have a way to
test them :)
THAT is an area where we do need to sort things out since the supplied client
library is always ditched anyway and the current Firebird one used instead.
From my point of view, splitting the fbird_ code from the ibase_ code and
building php_firebird against a firebird client would make sense, but as has
already been said - is not actually necessary - yet.
http://wiki.php.net/internals/windows/libs
The pages for ibase and fbclient need creating, and the project link for
interbase should be ibase but I could not work out what information should be
on them. In the past I have also been told that I need to make pdo_firebird
actually work which is yet another hassle that needs sorting even if the
current Firebird users do not use it :(
( To be honest I would rather remove pdo_firebird than php_interbase .... at
least until pdo_firebird could be re-writen to replace php_interbase
completely rather than our having to load both to get the functions currently
lacking in pdo - but that is a separate discussion )
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
hi,
Well when I originally reported the problems that were creeping into
php_interbase (linux and windows) I was told that I should fix them, and I
keep being told I should get involved more.
Not easy to fix issues yourself but you are getting amazingly more
involved, this step is more than welcome!
So
http://lsces.co.uk/lsces/wiki/index.php?page=PHPDevelopment
Had the M$ express stuff installed on my backup W2k machine it would
probably not have been a problem, but I can't upgrade it since I need W2k on
that machine to test against ;)
I've been through the mill with M$ installs trashing the rest of my
development environment in the past, so I am not going to risk it again.
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?
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.
If you can write tests (you and the PHP firebird community) and run
them using our sources and binary releases, that will already do the
job. That's all we need to keep the extension alive.Testing is not a problem ESPECIALLY while we can run multiple versions of
PHP on windows without the crap loaded into other applications which trash
the working version and overload it with a version which may not work. I
DON'T go with code that only has windows installers and would not test them
;)
It is rather simple to run multiple PHP version on windows. You only
have to uncompress the zip and run the tests. The fbclient will be
statically linked (bundled in the ext). You can call the run-tests.php
using the tests and script available in the src releases. I remember a
howto somewhere about running tests on windows without using nmake, I
will try to find it back.
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?
I have an older windows server that is running as backup at present which
I
could safely load some of the M$ stuff on - if it will work on W2k .....
But I'd prefer to stay inside my safety zone .....We can take care of the builds and port the firebird clients libraries
to Windows and/or MS tools. But we can do it only if we have a way to
test them :)THAT is an area where we do need to sort things out since the supplied
client library is always ditched anyway and the current Firebird one used
instead. From my point of view, splitting the fbird_ code from the ibase_
code and building php_firebird against a firebird client would make sense,
but as has already been said - is not actually necessary - yet.
Good point, especially as interbase is actually dead. That will simply
reflect the fact and we may add new 2.1 (or later) features. Feel free
to create the fbclient page in the wiki and to document what could be
done for 6.x (can't be renamed for 5.3).
http://wiki.php.net/internals/windows/libs
The pages for ibase and fbclient need creating, and the project link for
interbase should be ibase but I could not work out what information should
be on them. In the past I have also been told that I need to make
pdo_firebird actually work which is yet another hassle that needs sorting
even if the current Firebird users do not use it :(
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).
Cheers,
Pierre
Pierre Joye wrote:
hi,
Well when I originally reported the problems that were creeping into
php_interbase (linux and windows) I was told that I should fix them, and I
keep being told I should get involved more.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 ;)
I should have been fixing bitweaver on windows today :(
So
http://lsces.co.uk/lsces/wiki/index.php?page=PHPDevelopment
Had the M$ express stuff installed on my backup W2k machine it would
probably not have been a problem, but I can't upgrade it since I need W2k on
that machine to test against ;)
I've been through the mill with M$ installs trashing the rest of my
development environment in the past, so I am not going to risk it again.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/
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.
If you can write tests (you and the PHP firebird community) and run
them using our sources and binary releases, that will already do the
job. That's all we need to keep the extension alive.
Testing is not a problem ESPECIALLY while we can run multiple versions of
PHP on windows without the crap loaded into other applications which trash
the working version and overload it with a version which may not work. I
DON'T go with code that only has windows installers and would not test them
;)It is rather simple to run multiple PHP version on windows. You only
have to uncompress the zip and run the tests. The fbclient will be
statically linked (bundled in the ext). You can call the run-tests.php
using the tests and script available in the src releases. I remember a
howto somewhere about running tests on windows without using nmake, I
will try to find it back.
There was talk about dropping the .zip because the 'installer' was available.
Hopefully that idea has died on the vine.
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)
I have an older windows server that is running as backup at present which
I
could safely load some of the M$ stuff on - if it will work on W2k .....
But I'd prefer to stay inside my safety zone .....
We can take care of the builds and port the firebird clients libraries
to Windows and/or MS tools. But we can do it only if we have a way to
test them :)
THAT is an area where we do need to sort things out since the supplied
client library is always ditched anyway and the current Firebird one used
instead. From my point of view, splitting the fbird_ code from the ibase_
code and building php_firebird against a firebird client would make sense,
but as has already been said - is not actually necessary - yet.Good point, especially as interbase is actually dead. That will simply
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.
reflect the fact and we may add new 2.1 (or later) features. Feel free
to create the fbclient page in the wiki and to document what could be
done for 6.x (can't be renamed for 5.3).
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.
http://wiki.php.net/internals/windows/libs
The pages for ibase and fbclient need creating, and the project link for
interbase should be ibase but I could not work out what information should
be on them. In the past I have also been told that I need to make
pdo_firebird actually work which is yet another hassle that needs sorting
even if the current Firebird users do not use it :(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.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
hi Lester,
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?
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
Pierre Joye wrote:
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 :).
Still need gds32.dll for compatibility with Interbase. That is why a
php_firebird may now be appropriate. I'm doubt that Interbase will work with
the fbclient - in fact I suspect that even Interbase users would need a newer
gds32.dll from the Interbase install to access the current versions of
Interbase! Just don't know of anybody rich enough to use Interbase ;)
5.3.0 snapshot runs clean on the ibtest package but we do need to extend that
to add a few more blob tests. bitweaver runs except for a number of
'Deprecated' errors, so the blob functions are still fine. Just need to work
through the list of 'Deprecated' errors and see if we can do anything about
them AND maintain BC ....
1/ Assigning the return value of new by reference is deprecated
2/ The is_dst parameter is deprecated in mk/gmmtime
Only thing I spotted was a silly with php.ini. I had - path" - as the end of
the include path, and PHP5.3.0 then used the whole of the rest of the ini file
as the include path! Drop the '' leaving path" and everything is fine. I
think the '' was there originally because of a problem with it not being
added, but it does seem that it is no longer needed?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php