> the trouble is some of our clients add up to 300 defined fields
> sometimes. so i created an addional post for this. i was thinking
> about creating a single table with 300 columns to hold this data in
> flat format.

The day after you do that will be the day they want 301 custom fields.
You are also likely to start hitting some Firebird implementation
limit (eg. maximum size of non blob fields in a row, indices per table).

> i dont know if u understand where i am coming from. but if you do,
> your input would be much appreciated. :)
>

I believe I understand where you are coming from, but of course I can
not be certain. You want to give the customer the capability of
storing data that they want that may not be "in common" with other
customers.

Despite its drawbacks, the original approach seems preferable to me
than a mess of hundreds of indexed fields (I can't imagine performance
being good when several hundred indices are needing to be updated.)

Maybe a variation on your original design as mentioned by Set may
reduce your current design's drawbacks. I can't say I am entirely
comfortable with any of the designs for this purpose, but I think the
avenue you are pursuing with this idea is going to cause you more
problems in the long term than it solves.

Adam