unordained wrote:

>I don't see firebird's syntax differences as a significant obstacle to adoption. I see abstractions
>(ODBC, etc.) as one such block (lets users treat all database systems alike, when there are
>significant differences they shouldn't be shielded from); the large difference in feature-sets
>between something like mysql and firebird ... that's also one. The biggest obstacle however is when
>people never learn how to learn; they don't learn to experiment, they don't learn to ask for help,
>they don't learn to guess, they don't learn to look for familiar features under new names (auto-
>increment vs. generator). Such people can't cope with anything new, unless you make it absolutely
>identical -- and then there's no point in doing so.
>
>
>

I agree with all your points. But the idea at the starting of this
thread was not complain about a lot of work extra to get better results.
My complain was about a *all/standard sql/simple* feature present in any
db engine requiring a lot of *dirty work* in firebird to get same
result. The complain was about why any user defining integrity checks
and having a few a foreign values (and see how relative is the *few*
here) must do a lot of additional work before can use foreign keys!
Foreign keys tables having little (?) amount of data in Firebird are
unusables for the b-tree index strucuture. The inserts in the main table
are sloowly in a poor way.That is not about learn new skills or get a
better use of the DB, is just dont work in acceptable way. I just ask
any to confirm that, and get many confirmation from Helen and Martin,
two people knowing in deep Firebird so my choices are ended. Again, i
know Acces is less secure, etc. but still outperform Firebird whit the
same set of data. Is a fear , but is the true. I expect be clear, sorry
by my poor english.

TIA.

German.