Hi Rudi,

> the script is a little long (to write it here, abauto 33 tables with
> some Triggers), but if is not a nuisance, i can send it to your
> e-mail account.
>
>
> *************************************
> yes it has autoddl on!
>
> SET TERM ^ ;
>
> SET SQL DIALECT 3^
> SET AUTODDL ON^

OK. So that's not the cause of the problem. By the way, you can leave
out the COMMITs after the DDL statements now.

> CREATE DATABASE 'C:\Documents and Settings\...mydb.gds'
> USER 'SYSDBA' PASSWORD 'masterkey'
> DEFAULT CHARACTER SET ISO8859_1^
> **************************************
> yes is commited after the create table declaration!
>
> CREATE TABLE "dml" (
> "Id" INT64 NOT NULL,
> "Accion" CHAR(1) NOT NULL COLLATE ES_ES,
> "Campo" VARCHAR(128) NOT NULL COLLATE ES_ES,
> "Valor01" VARCHAR(128) NOT NULL COLLATE ES_ES,
> "Valor02" VARCHAR(128) COLLATE ES_ES,
> "Valor03" VARCHAR(128) COLLATE ES_ES,
> "Valor04" VARCHAR(128) COLLATE ES_ES,
> "Usuario" VARCHAR(32) NOT NULL COLLATE ES_ES )^

I can think of two more possible causes:

1.
Somewhere in your script you forgot the double quotes around the "dml"
table name. It is then seen as case-insensitive and translated by the
server to "DML" (even if you spelled: dml). Table DML doesn't exist,
hence the error.
(Hmmm... that doesn't seem likely because you said the exact same
script worked well in IB_SQL.)

In connection to this: ask yourself if you *really really* need those
case-sensitive object names. If not, drop all the double quotes and
save yourself a lot of headaches. You can spell Valor01 or VALOR01 or
valor01 and it'll all mean the same thing.

2.
You perform a DML statement - like inserting a record - upon table
"dml". This can sometimes go wrong even if your DDL statements have
been committed. The general "safe rule" is:
- Put only DDL statements in your create script. And make sure to
commit of course (but with AUTODDL on, that's been taken care of).
- If you want to perform DML afterwards: first disconnect, then
reconnect and run a second script.


Another thing: you can use the TIB_Script's OnError event to find out
exactly at what point the error occurred. Make the event handler show
the SQL statement. The "Line 1" from the error message means the first
line of the statement, not of the script, so that doesn't help you
much.


If you still can't find the error, feel free to send me the script or
post it here (I think the list can handle it).


Greetings,
Paul Vinkenoog