Subject | FB 1.5 - Index Limit |
---|---|
Author | Marc Batchelor |
Post date | 2005-04-23T03:39:02Z |
Hey all,
I'm trying my level best to get Enhydra Shark to work with Firebird.
But, after going through all the pain of defining Firebird to Octopus,
generating Octopus load files based on a MySQL database, and getting
all the moons to align properly with constraint-names and such - I've
hit a brick wall.
They have many indexes and primary keys on columns that are 254 in
length. Additionally, they create compound indexes on columns where
the total length in bytes is much longer than 252 bytes.
Well, I remember back in my DB2 days that DB2 UDB had a similar index
limit. But, tweaking a configuration file by adding a
barely-documented parameter doubled the index length. All you had to
do is re-create the database to get the index length doubled.
So - is it possible that there's some kind of tweak that will let me
break through this wall?
Note that statements like "using surrogate keys would be better"
aren't really applicable here unless you're thinking it's "better" to
dive into Shark's code and re-write their logic.
This is a case where Oracle, DB2, MSSQL, Postgres, MySQL, and many
others are capable, but where Firebird seems to fall flat.
Thanks for any help you can provide.
I'm trying my level best to get Enhydra Shark to work with Firebird.
But, after going through all the pain of defining Firebird to Octopus,
generating Octopus load files based on a MySQL database, and getting
all the moons to align properly with constraint-names and such - I've
hit a brick wall.
They have many indexes and primary keys on columns that are 254 in
length. Additionally, they create compound indexes on columns where
the total length in bytes is much longer than 252 bytes.
Well, I remember back in my DB2 days that DB2 UDB had a similar index
limit. But, tweaking a configuration file by adding a
barely-documented parameter doubled the index length. All you had to
do is re-create the database to get the index length doubled.
So - is it possible that there's some kind of tweak that will let me
break through this wall?
Note that statements like "using surrogate keys would be better"
aren't really applicable here unless you're thinking it's "better" to
dive into Shark's code and re-write their logic.
This is a case where Oracle, DB2, MSSQL, Postgres, MySQL, and many
others are capable, but where Firebird seems to fall flat.
Thanks for any help you can provide.