| Subject | Re: [firebird-support] Re: Unable to drop tables and fields |
|---|---|
| Author | Helen Borrie |
| Post date | 2011-05-08T05:22:16Z |
At 01:23 PM 8/05/2011, klmsw45 wrote:
But what I'd recommend now is to upgrade your server to the newest sub-release of the version you are using and then
1) take a backup of the database in that server, using the gbak that comes with it
2) restore that backup under the same conditions
...and then try to drop those objects.
The reason I suggest that (and why it's what I'd likely to do first if you were a customer of IBPhoenix) is that I recall a problem somewhere along the way with dependencies. At the moment I don't have time to research it but you could browse the Bug Fix sections of the various release notes yourself. If you are already using the last subrelease of a no-longer-supported Firebird version, e.g., 2.0.6 or 1.5.6, then it's likely you'll never have a gee-whizz solution, other than upgrading.
If it still flops, rebuild the entire database from extracted metadata (isql -extract), edited to remove the objects you don't want, then pump the data. Sounds complicated but it's not, really, if you use one of the reputable data-pumping tools (look in the Downloads section of the IBPhoenix website for links).
Incidentally, it is also worth inspecting the extract script to check whether there's something you overlooked, such as a CHECK constraint that depends on the problem table somehow.
./hb
>Hi Helen,Hmmm, I doubt I'll ever be elevated to "Goddess". There is one and only one Goddess around here! ;-)
>
>It's an honor to receive a reply directly from one of the Gods (Goddeses?) of the Firebird community!
>Thanks for all your excellent work on the documentation (among other contributions)Thanks!
>I removed the permissions except for SYSDBA (which has all permissions), I'm always logged in as SYSDBA, still no good. Won't let me drop.No, not unless you are a customer of IBPhoenix.
>
>Hey, can I send you this DB via .fbk and let you have a look?
But what I'd recommend now is to upgrade your server to the newest sub-release of the version you are using and then
1) take a backup of the database in that server, using the gbak that comes with it
2) restore that backup under the same conditions
...and then try to drop those objects.
The reason I suggest that (and why it's what I'd likely to do first if you were a customer of IBPhoenix) is that I recall a problem somewhere along the way with dependencies. At the moment I don't have time to research it but you could browse the Bug Fix sections of the various release notes yourself. If you are already using the last subrelease of a no-longer-supported Firebird version, e.g., 2.0.6 or 1.5.6, then it's likely you'll never have a gee-whizz solution, other than upgrading.
If it still flops, rebuild the entire database from extracted metadata (isql -extract), edited to remove the objects you don't want, then pump the data. Sounds complicated but it's not, really, if you use one of the reputable data-pumping tools (look in the Downloads section of the IBPhoenix website for links).
Incidentally, it is also worth inspecting the extract script to check whether there's something you overlooked, such as a CHECK constraint that depends on the problem table somehow.
./hb