| Subject | Re: [firebird-support] Re: Version compatibility |
|---|---|
| Author | Helen Borrie |
| Post date | 2011-05-03T08:44:28Z |
At 06:13 PM 3/05/2011, L Lloyd wrote:
What you (L Lloyd) are talking about is compatibility of *client applications*, that were written for old Firebird server and API versions, with a newer API and server. It is very common to bump into incompatibilities in that department, for obvious and (sometimes) less obvious reasons.
Unhappily, those reasons, all too often, have to do with unwise coding practices that app developers have indulged in, usually going back to their InterBase days, to take advantage of bugs (a.k.a. "undocumented features") viz., things you shouldn't have been able to do but discovered that you could do and went ahead and did it, against advice. These can range from ambiguous SQL syntax that was allowed to slip through the parser, to insecure function calls and buffer overloading (and a lot more besides!)
As these ugly bits gradually get fixed or excised, the applications that relied on their presence start to show cracks when trying to work with the improved versions.
./heLen
>UnlessDon't you mean "If"?
>you are using a program that uses FirebirdDon't get confused between two different issues. The OP questioned about the compatibility of older ODS databases with newer servers. As a general rule, newer servers can read databases of older ODS....but there is no guarantee that you won't bump into problems related to changes in the way the newer ENGINE does things....the storage of NULL index keys is an example. As others have said, it doesn't make much sense to try to oscillate a database between two server versions.
>then you are stuck to which ever version it's
>coded for. Like Spacial Audio SAM Broadcaster
>version 3 is coded for Firebird 1.5, install 2.5
>and it breaks with a "Ver" error. >.<
What you (L Lloyd) are talking about is compatibility of *client applications*, that were written for old Firebird server and API versions, with a newer API and server. It is very common to bump into incompatibilities in that department, for obvious and (sometimes) less obvious reasons.
Unhappily, those reasons, all too often, have to do with unwise coding practices that app developers have indulged in, usually going back to their InterBase days, to take advantage of bugs (a.k.a. "undocumented features") viz., things you shouldn't have been able to do but discovered that you could do and went ahead and did it, against advice. These can range from ambiguous SQL syntax that was allowed to slip through the parser, to insecure function calls and buffer overloading (and a lot more besides!)
As these ugly bits gradually get fixed or excised, the applications that relied on their presence start to show cracks when trying to work with the improved versions.
./heLen