Hello Lester,
thanks for the reply. It was exactly what you said, three
varchar(32000) fields in the table definition was just too much.
I also know ADODB to be really efficient. But from what I remember the
datadict part is contributed. I mean, I checked the functions and they
are all correct. ExecuteSQLArray() is nothing else than a loop
executing [$conn->Execute()] each array field/line. it should normally
return an error code. I really don't know why it does not.

OK, to use BLOBs as a text equivalent would cause a lot of work,
because my application has become really large, many modules. Next
thing is the application is able to use PostgreSQL, MySQL and
FirebirdSQL to store the data, other databases supported by ADODB will
be added as soon as I have the possibility to test them, then the
search engine I've written for my application that is able to search
over many fields at a time. I would have to change quite a few things.

To keep it short, I just reduced the varchar length to 4000 which
should be enough in most cases.

Well, thanks again.

Best regards

Ralf

--- In firebird-php@yahoogroups.com, Lester Caine <lester@...> wrote:
>
> sc_odo wrote:
>
> > Alan, your question about committing transactions after every
> > statement was a good one.
> > I added some code to start & commit transactions in each loop and
> > tried again. Now I'm getting a warning from ibase_commit starting
> > after the 9th table that was successfully created:
> > ibase_commit(): unsuccessful metadata update new record size of 96124
> > bytes is too big TABLE KASSA_0 in
> > /srv/projects/adodb/drivers/adodb-ibase.inc.php on line 154
>
> Maximum row size is 64kb so there are too many large fields in that
> table. If there is a large text field it may be worth moving it to a
> blob? Otherwise break the table in two and just access one half or the
> other.
>
> > What I don't understand is why the creation of the table doesn't
> > return an error.
>
> ADOdb is set to be silent on errors so that you don't have to keep
> handling situations such as 'record not found' crashing the script.
Just
> take off the '@' if you want the error, or better still, the create
> functions do normally give a 'false' reply if the SQL did not complete.
> We do run an extra check though in bitweaver, and try to read from a
> table to ensure it exists and has not been deleted outside the
program ;)
>
> > Does this warning mean that this table has too many fields or does the
> > field size exceed maximum size?
>
> It's the number of bytes needed by the fields rather than the number of
> fields. You will need to either reduce the varchar fields, or split the
> table. Using multiple tables with links together is better than one
> large table.
>
> --
> Lester Caine
> -----------------------------
> L.S.Caine Electronic Services
> Treasurer - Firebird Foundation Inc.
>