Subject | Re: [firebird-support] mysqldump equivalent? |
---|---|
Author | Ann W. Harrison |
Post date | 2004-04-15T22:07:43Z |
At 05:26 PM 4/15/2004, Emile Snyder wrote:
continue to use command line tools, so I can't recommend one from
experience. The ibphoenix.com website lists a bunch. I know most of the
people who develop them and each has rare and keen insight into the
problems of database administration - though their tastes vary wildly.
ISQL. Gbak (backup tool) also has a mode where it backs up only
metadata. That's binary and CVS hates it, so I'd stick with the isql extract.
my_prompt> isql xyzzy.fdb
ISQL> alter table foo add field bar1 numeric(9);
ISQL> commit;
ISQL> update foo set bar1 = bar;
ISQL> commit;
ISQL> alter table foo drop field bar;
ISQL> commit;
ISQL> alter table foo add field bar numeric(9);
ISQL> commit;
ISQL> update foo set bar = bar1;
ISQL> commit;
ISQL> alter table foo drop field bar1;
Maybe someday somebody will lift that silly restriction and replace it with
an actual check for out of range data. For indexed fields, the check is
next to free.
Best regards
Ann
>Thanks for the isql pointer. Could you recommend a good open sourceI could suggest a dozen, but the fact is that I'm an ancient troglodyte and
>tool to manage firebird schema changes?
continue to use command line tools, so I can't recommend one from
experience. The ibphoenix.com website lists a bunch. I know most of the
people who develop them and each has rare and keen insight into the
problems of database administration - though their tastes vary wildly.
> One of the reasons I like beingYou could certainly make the changes and extract the schema with
>able to get text out is version control; I can have my db schema checked
>into CVS along with the set of cgi scripts that interact with it. Is
>there some non-text dump way to get the same effect?
ISQL. Gbak (backup tool) also has a mode where it backs up only
metadata. That's binary and CVS hates it, so I'd stick with the isql extract.
>Also, I was asking because I couldn't figure out how to get a particularSure
>alter to work. I have some tables with NUMERIC(10) fields. The perl
>DBI interface used by the script we have (developed when it was talking
>to Oracle) can't seem to handle those, I get complaints about 64bit
>stuff. So I want to change them to NUMERIC(9), which worked ok on a
>test table. However, if I do
>
>alter table foo alter column bar type numeric(9);
>
>in isql it complains that:
>-Cannot change datatype for BAR. Conversion from base type BIGINT to
>INTEGER is not supported.
>
>All the values in the column are such that they will in fact fit in a 32
>bit int. Any suggestions?
my_prompt> isql xyzzy.fdb
ISQL> alter table foo add field bar1 numeric(9);
ISQL> commit;
ISQL> update foo set bar1 = bar;
ISQL> commit;
ISQL> alter table foo drop field bar;
ISQL> commit;
ISQL> alter table foo add field bar numeric(9);
ISQL> commit;
ISQL> update foo set bar = bar1;
ISQL> commit;
ISQL> alter table foo drop field bar1;
Maybe someday somebody will lift that silly restriction and replace it with
an actual check for out of range data. For indexed fields, the check is
next to free.
Best regards
Ann