Hi,

>Aaah - OK. I take it that you have all of this database in one huge
>table. Yes, the Fb 2 changes should help increase the capacity of a
>table
>beyond the ~2 billion record limit that prevails now.

I don't reach this limit. Also i can insert smaller blobs. But when i
try with a bigger one it fails.

>Yup. You've run into a problem with the size of tables. We've got a
>fix in V2, which is teetering on the edge of an alpha test. For now,
>the best alternative that I know of is to split your table in two.

I think the problems is with the record size, not with the table size.

> So, if the row enumeration limit is your problem, then breaking up the
> table seems to be your "Hobson's choice". A normalized archiving

scheme

> comes to mind as both the short and the long term solution.

I very dificult normalize a database with only 1 table 3 fields.

CREATE TABLE STATEMENTS (
CUENTA APLHA_10 COLLATE WIN1251,
FECHA_PROCESO FECHA,
FRF_STATEMENT ST_BLOB);

( cuenta means account number, fecha_proceso means procesed date and
of course the blob )


divided the compresed ( with abrevia ) blob in 3 or 4 parts and store
in diferent tables is not my idea to normalize the blob but i will try.

also i can try

create FRF_STATEMENT_part1, FRF_STATEMENT_part2 and part_3 and divide
the stream in difrent's fields.


i hope one of these ideas works,
other idea is very welcome.

regards,
Dennis Ortiz