Subject | Re: FB 1.5.x CS on Linux - Primary Key FAILURE |
---|---|
Author | Bozzy |
Post date | 2005-04-05T14:18:39Z |
Thanks Helen, this is the kind of USEFUL answers everyone should give.
Just a couple of comments.
statements one by one, as isql does by default. So is this a fault of
that tools? I think it would be much better if FB would tell us we're
doing something wrong, particularly in delicate situations like unique
constraint definitions.
Unique Index aren't been created, while actually FB tells me that the
table HAS GOT a Primary Key AND it's Unique Index!
what we're now discussing of, and BTW I've realized that I can't even
do what I was initially trying to do. To make it short, I have to
convert a set of DBASE tables into FB. I've written a tool that does
this, but now I need to add a feature that lets me rebuild *from
scratch* any of the previously created tables. The ideal thing would
be recreating and reloading data into that tables into a single
transaction, in order to not disturb other (read-only) applications.
I've however encountered the first obstacle when FB refused to insert
a record into a newly created (but not committed) table. That's OK, FB
can't write data into an "ethereal" object so it raises an exception,
I can understand it.
So IMHO in the same manner FB should raise an exception when I try to
alter an "ethereal" object, as you've stated, and also more important
it shouldn't tell me that this object has got its PK when it's not true.
Regards,
Bozzy.
Just a couple of comments.
> This is one of the "foolproofing" areas that has beenIt depends on the tool. Not all Firebird managers out there commit DDL
> discussed: that ALTER TABLE statement should somehow
> be made to cause an exception because
> the object it is requesting to alter is still ephemeral;
> but it doesn't; the tool relies on the assumption that
> AUTODDL is on.
statements one by one, as isql does by default. So is this a fault of
that tools? I think it would be much better if FB would tell us we're
doing something wrong, particularly in delicate situations like unique
constraint definitions.
> Yes, finally that commits the transaction. So, now, the[...]
> database has the new version of the table (empty) but not
> the PK constraint.
> Yes; but the unique index for the primary key constraintWell, that would be ok IF Firebird would tell me that the PK and its
> does not exist.
Unique Index aren't been created, while actually FB tells me that the
table HAS GOT a Primary Key AND it's Unique Index!
> As a side-note, there is another DDL syntax that works likeWell I know that ;) In fact my actual needs were a bit different than
> your two statements: RECREATE TABLE.
what we're now discussing of, and BTW I've realized that I can't even
do what I was initially trying to do. To make it short, I have to
convert a set of DBASE tables into FB. I've written a tool that does
this, but now I need to add a feature that lets me rebuild *from
scratch* any of the previously created tables. The ideal thing would
be recreating and reloading data into that tables into a single
transaction, in order to not disturb other (read-only) applications.
I've however encountered the first obstacle when FB refused to insert
a record into a newly created (but not committed) table. That's OK, FB
can't write data into an "ethereal" object so it raises an exception,
I can understand it.
So IMHO in the same manner FB should raise an exception when I try to
alter an "ethereal" object, as you've stated, and also more important
it shouldn't tell me that this object has got its PK when it's not true.
Regards,
Bozzy.