Quote:
Originally posted by md_doc
did you have the exact same title for the thread? that would probably cause it to reject you from posting it. |
it was the same title for the thread and i panicked because my article didn't showed up
after have submited it (first it showed the 30s warning ) and saw the above article ...
Anyway here is my article body
Firebird 1.0.3 maintenance update
The Firebird project is pleased to announcement the immediate availability of the v1.0.3 maintenance release. It is a testament to the robustness of Firebird 1.0 that no major problems have been found that have required fixing. However, almost six months have passed since the Fb 1.0.2 and several bug fixes and enhancements have appeared. Rather than letting them molder indefinitely it is better to get them out into the big wide world.
One of the main bug fixes was for a problem that was inadvertently introduced in Fb 1.0.2. Gbak and gfix could longer use the service manager api to work on remote servers.
Another important fix was in the way event handlers were set up. Multi-threaded operating systems were setting them up incorrectly, leading to hard to diagnose errors.
One new feature was added - the removal of an artificial limit on maximum indexes per table. This had been set at 64. IBPhoenix had a client who needed more and subsequently carried out the work to remove this limit for them. The readme documents the new limits. It also (hopefully) explains adequately that having a multiple indexes (never mind 64 or 200 or more) is a huge performance drag on applications that are primarily for data update. Just because you can now define 1000 indexes for a table doesn't mean that you should!
An MSVC based control panel applet is now part of the Firebird 1.0 source tree and builds automatically with the rest of the code. It re-uses existing code in the source tree to manage Firebird services. The reasons for including this are quite simple. Firstly, as a server control applet it is a core tool and as such should be buildable with the rest of the server. Secondly, by re-using code we can consistently manage the behaviour of the server. This is not so important for Firebird 1.0 (because of a de facto feature freeze) but is likely to become important for Firebird 1.5 and beyond. Thirdly, it produces 50% smaller code than Delphi coded cpl applets. Firebird has a great tradition for lean and mean and there is every reason for this to be continued, even in an age of 80Gb disc drives.
A half bug-fix/half feature from Firebird 1.5 has been back-ported. Database attachment times had an artificial delay of up to one second due to a code loop that wasn't being broken out of. Local connections are now almost instantaneous.
While preparing the installable binaries for Firebird 1.5 release candidates it became clear that the Firebird 1.0 and 1.0.2 installers have a major design flaw. When doing an uninstallation they don't check to see if they are the current Firebird version. If Firebird 1.5 is installed into a system where Fb 1.0.0 or 1.0.2 exists and then Fb 1.0.0 or 1.0.2 are subsequently uninstalled they will remove the registry entries for Fb 1.5. Firebird 1.0.3 fixes this problem. If you are planning on installing Firebird 1.5 simultaneously on a system with Firebird 1.0 it is highly recommended that you upgrade to Fb 1.0.3 for this reason alone.
Simultaneous and harmonious existence between Firebird 1 and 1.5 still hasn't been achieved. The remaining problems will be dealt with in subsequent maintenance releases of Fb 1.0 and release candidates of Firebird 1.5. (hopefully) explains adequately that
having a multiple indexes (never mind 64 or 200 or more) is a huge performance drag on applications that are primarily for data update. Just because you can now define 1000 indexes for a table doesn't mean that you should!
Dev Shed Forums Sponsor:
June 5th, 2003, 03:23 AM
Re: Firebird 1.03
it was the same title for the thread
Del.icio.us
Digg
Google
Spurl
Blink
Furl
Simpy
Y! MyWeb
Linear Mode
