Commented by: @ibaseru

completely disagree. support of previous ODS does not help to migrate. Moreover, there are some people that uses FB 2.5, and work with ODS 10 databases. Compatibility lowers benefits of 2.5 and does not force them even to backup/restore.
"Classical hard way" to backup with old FB and restore at new is the most correct way of upgrade.

Commented by: @aafemt

One must be completely crazy to uninstall old server and then install a new one at once, without a long testing period when old and new databases work in parallel.

Commented by: @hvlad

michalk1,

as you said :

> upgrade to FB 3 would require to go the classical hard way - backup all databases first under previous FB version, uninstall old Firebird, install Firebird 3, and restore the backups.

Imagine we have pre-ODS12 provider which is:

> able to make backup of the older ODS databases on its own, just as previous FB versions did.

Please, explain - how such provider could make "classical hard way" more easy ?
It will require backup\restore to use FB3 features, as it will not be able to use FB3 features at pre-ODS12 databases.
Where the profit ?

Commented by: @dyemanov

Dimitry, such a long and hard testing can be performed in the head office and then just "upgrade now" command is sent to the branches. They don't need to test everything themselves (and usually they don't have knowledge to do it anyway). That said, I agree that v2.5 + v3.0 co-existence is not that hard at all and can help with the migration.

Commented by: michalk1 (michalk1)

To give more details about our, say, "easy deploy" Firebird usage scenario. We distribute it together with our application as a replacement of former dbf and paradox databases. Our customers are mainly users with no database skills at all, so any upgrade process must be seamless and controlled automatically by the application with minimum (if any) user interaction.

2 Dimitry Sibiryakov: Of course, we thoroughly test any new Firebird version before we allow to use it with our software.

2 Vlad Khorsun: It would allow to separate database migration process from Firebird installation. Installer just replaces Firebird, which is relatively easy and quick step. All the more difficult and potentially lengthy database migration process is done later, already controlled from running client application, without administrator privileges and user interaction. Databases could also be migrated later, progressively at a time when any of them is needed. All this requires FB to be able to read old ODS databases. Yes, we could backup all the databases as a part of new version installer prior to older FB uninstallation, but this would be an uncomfortable and ugly solution from users POV.

2 Dmitry Yemanov: Yes, as i wrote, we have to test the application compatibility before we distribute it with any new server version. As for running more servers at a single machine, I prefere to avoid it whenever possible, because it usually requires end user support. For example, the second server would run at a different port, which would have to be allowed in firewalls, redirected at router NATs etc., which are actions that most users don't understand. In many cases, where the databases are placed locally, the problem could be solved by older embedded FB version, but i would prefere to make the migration easy even for users with dedicated server machine.

Commented by: @ibaseru

michalk1,

For example, when you install FB 2.5 over FB 1.5, you need to make backup with 1.5. This is the rule, to allow "dummy user" to return to 1.5 if there will be any problems with new installed FB 2.5.
Moreover, if you "upgrade" database to new FB version, definitely some preparation need to be done with current FB version. Usually you never know that DB may pass backup/restore even if you do not change FB version.

Yes, upgrade must be simple for dummy users. But I think that this is only at application. And it's bad to allow users work with FB 3 with older ODS databases.

And, finally, I think that you sould upgrade user systems to 3.0 only if there is any benefit for user itself. In most cases user does not care which FB version is used by some software. Maybe, there is no reason to upgrade old users. Look at components like FastReport, for example - they still support old Delphi versions.

Commented by: michalk1 (michalk1)

kdv,

> Usually you never know that DB may pass backup/restore even if you do not change FB version.

To assure that it is ok, backup can be restored to a new database, different from the original one.

> And, finally, I think that you sould upgrade user systems to 3.0 only if there is any benefit for user itself.

Here I absolutely agree, there must be substantial benefit for the users. But FB 3 features look promising - full SMP support, faster network protocol etc.

>Look at components like FastReport, for example - they still support old Delphi versions.

This actually seems as an argument towards better backward compatibility ;-)

Commented by: @sim1984

michalk1,

You understand that the "full SMP support" implemented in the engine database firebird? The engine is engine12.dll (http://engine12.so). From firebird 3.0 using engine11.2 you can only get what is implemented as a separate plug-ins. It's not worth it.

Commented by: michalk1 (michalk1)

Denis, in my case the old ODS provider is needed just to simplify the migration process. It would be used as a one-time data source for backup or a data pump procedure, that would transfer old database contents into a newly created database. Once migrated, the database will be accessed solely by the new, native FB 3 engine. I don't want to flood the discussion with more details, as it's getting slightly off-topic, and it probably doesn't belong into the tracker anyway.

Commented by: PizzaProgram Ltd. (szakilaci)

Please change
Affects Version/s: 3.0 RC1
>> to newest 3.0.x & 4.x too.

We agree with michalk1 completely.
Backward compatibility is a MUST.
(It was always a famous bonus of ALL previous Firebird engines and made it possible to flawlessly upgrade and keep old copies too.)

- Q: What happens if somebody installs a program that is using FB3.0.3 ?
- A: It will completely break our program. :-(

- Q: What happens if we change from FB2.5 to 3.0 ?
- A: We will completely break other programs currently co-exists fine with ours. (Like Invoice APPs !!! , etc. )

- Q: How could a new DEMO program and an older version a customer bought before co-exist ?
- A: It can not until this problem is fixed by the FireBird developers. So we can NOT change to FB3.0 / 4.x ... risking first scenario can happen ANY time. :(

Please finish it for 3.0.4 and 4.0 beta.

Commented by: PizzaProgram Ltd. (szakilaci)

[A possible solution]

Instead of duplicating everything in 1 DLL,
How about the 3.0.4+ installer would copy a (renamed?) DLL file of a 2.5 version to a '\bin25' directory
and forward all PRE-ODS function-calls to that ?

\Bin
fbclient.dll
...
\Bin25
fbclient25.dll
...

instead of just showing "ODS version error" message.

IMHO it's a simple 2 line-program code of work. Isn't it? (I'm just asking, don't know.)
if ods < 12 then ...

Commented by: PizzaProgram Ltd. (szakilaci)

It's been almost 4 years past.
Any progress on supporting pre-3.0 DB?
(At least to Read and Backup...)

Any FB3.x install KILLS the possibility to reach <=2.5 files.

Now 7 years, still not upgrading from 2.5 because too many deployment issues with 100s of customer fdbs.

Would Engine11 be possible?

We had some kind of ISC API->OO API envelope that allowed to use Firebird 2.5 embedded to be used as a provider for Firebird 3.0 server. Nobody was interested and Firebird providers' API was changed since then so the project was buried.

In any case it was easier to run Firebird 2.5 and 3.0 servers at the same hardware than to set the provider up.