Thanks, that was very informative! I'll try to include more information to better explain my situation.

Our software uses SQL scripts to create databases that we can then interface with. After installing 2.5 I can access and modify existing databases. If I roll back to 2.0, I can still access and modify those same databases, but the script to *create* a database no longer works and instead throws an ISC error (335544375). Since it works in machines running a virgin 2.0 install, but not on 2.5 or a machine that has been rolled back from 2.5, which suggests to me that the uninstaller is missing something.

Let me know if there is any additional information I can provide that would further explain my situation.

--- In firebird-support@yahoogroups.com, Helen Borrie wrote:
>
>
> At 11:07 a.m. 9/01/2013, Alexandre Benson Smith wrote:
>
> > > Could it be the ODS upgrade ?
>
> At 11:19 a.m. 9/01/2013, halaekinree wrote:
>
> >Good thought, but the database structure is still the same - the only thing that changed is the server version.
> >
> >Thanks for the suggestion though!
>
> You missed the point of Alexandre's question. The on-disk structure (ODS) of a database is upgraded when you restore under a newer server a database with an older ODS than what the newer server creates. The actual *data structures* of the user data are not changed by this, although the structures of the metadata usually are. That's why databases are not backward-compatible and one strong reason not to commit a production database to such a change without thorough lab work.
>
> The API (application programming interface, the layer that applications use to communicate with databases through the server) is also likely to undergo changes in a major version upgrade. This will affect how user applications access data, in ways that would be hard to guess without some meaningful symptoms. For that reason, performing a major server upgrade is a bad idea unless you are in control of what the application can do to work with the API changes.
>
> You might be getting permission/privilege problems, if you lost the security database in the process of installing the new version. That problem is relatively easy to fix if you still have the security database (security2.fdb) that shipped with your application package.
>
> You haven't given enough information for anyone to tell whether your troubles are coming from ODS changes, API changes, or both. There are expert's techniques that can sometimes work to "downgrade" a database to an older ODS. If you have gotten yourself in the position of having wrecked a production database without any backups you can restore and revert to, you would be best advised to get professional help. Whatever you do, hang on to any backups and take a file copy of the database in its current state.
>
> Alternatively, the vendor of your application software may have tools to deal with this kind of mess. It's worth trying.
>
> ./heLen
>