Federico Tello Gentile wrote:

> the script I ran was like this:
> drop table sometable;
> ... 7 in total
> drop domain something;
> ... 8 in total
> drop generator id_generator;
> create domain something
> ... 8 in total
> create table someting
> ... 7 in total
> create generator id_generator;

No commits in between. You see, isql would commit after *each*
statement. To do the same in FlameRobin 0.2.5, you'd have to:

drop table t1...;
commit;
drop table t2...;
commit;

etc.

> That was the script. It had no errors, and I ran it pressing F9 and if
> no error message appeared, I pressed F5 (commit). sometimes when i had a
> typo or a missing comma, I rolled back after pressing F5.

There are potential bugs if you execute DDL and don't commit right away.
For example, the one I know for sure: it you add a column to table and
update it before you commit it makes a mess.

>>Please note that FlameRobin simply parses the input script and sends it
>>to Firebird, it does not alter anything, so if the script makes hell in
>>FR, to will probably do it in isql too.
>
> Probably, but I'm not going to test it... If anybody wants try I can
> send you the full script.

If it's not the problem, send it to me privately. Perhaps I'll notice
something.

> I don't know what is the big differnce since I always pressed commit or
> rollback after every single execution.

In FlameRobin - a "single execution" run your entire script in a single
transaction. In isql, transaction was commited after each DDL statement.
Like I wrote, in FR 0.4.0 and higher you'll be able to SET AUTODDL ON,
and make it run as isql.

> After that error, I could still connect, sometimes not at the first try,
> could query, but not update or insert to that table.
> It alowed violating the foreign key, rerunning the full script dropping
> and recreating (all objects) did not solve the problem.
>
> The DB was created with a user, not sysdba. The connections are always
> using the user account. Never sysdba.

You could also prepend "SET AUTODDL OFF;" to script and run it in isql.
See what happens. You'd probably run into same problems.

--
Milan Babuskov
http://www.flamerobin.org