|
Robert,
I think IB 7.1 supports temporary tables,
but I have never found a good reason to use them in FB.
A dBase app is necessarily going to be very
different from one that works with either IB or FB, so you are going to find
that you have to re-think alot of the things that you do.
Stored procedures often help fill the void
when you think that you need a temp table, but the FB/IB language is so rich
that you can often get away without having to even think in terms of temp
tables.
I've converted a whole bunch of apps from
Paradox/dBase to IB/FB, and have found that the best solution is to re-think the
way that you want to access the data. A good tool that can show you not
only query plans, but also number of reads is essential. Sometimes a full
table scan in IB/FB is more efficient than trying to jump through hoops ensuring
that the index that you think is the best is the one used.
Stuff that looks like it would suck
performance-wise in Paradox or dBase is often very fast when you let the server
do all of the work. Also, if you brush up on using joins, you can make the
server respond much faster than you could ever get a flat-file db to
respond.
Lots of people come unstuck when trying to
use sub-selects in queries. These will always run slow, and can almost
always be re-written as joins which run quickly, but the join syntax to avoid
sub-selects is often not available in dbAccess methods like the
BDE.
There are some cool functions (such as
coalesce) which are available in FB (but not IB) which can remove sub-selects
& make your query faster, but unfortunately they also tie you to a specific
engine. I like to use the "break" keyword in my FB databases, but it
doesn't work in IB.
If you give us specific examples, I'm sure
that members of the community can show you how to translate what you want to do
in dBase to what you should ask a FireBird server to do.
HTH
Trevor
|
_______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
