--- In firebird-support@yahoogroups.com, "Gustavo" <gusm@d...> wrote:

> Adam:
>
> I use this local temporary database because I am migrating an

application which used dBase tables with BDE and it uses temporary
tables. I also think that using it I reduces the wire traffic when
processing the data. Is it true or I am wrong?

Having migrated a Paradox / BDE application to Firebird, I can assure
you that Firebird works very differently. For example, if you ran a
query like

select Name
from Employee
where ID = 1

The BDE would transfer across the wire the entire Employee table.
This would probably be between 100k and 1MB, which is a noticable
length of time on even a 100Mbps LAN. Start joining it with other
tables containing 30 or 40MB of data and you can have a snooze while
your application launches.

Firebird processes this SQL on the server, and only returns the Name.
Furthermore, if the field Name is a varchar, then it only returns the
characters that are stored in there + 2.

So my Name which might be varchar(70) only returns 6 characters if ID
1 was 'Adam'. There is some expense in the protocol, but it is not
very much, and third party tools such as Zebedee can perform on the
fly compression if it is a real issue.

If your application continuously requests the exact same piece of
information, then a local cache will help with performance, otherwise
it is just another thing that can go wrong. Remember that when you
run some SQL in Firebird, it is executed on the SERVER, not at the
CLIENT. This is a contrast to how the BDE worked, and something that
you need to understand well.

For example, I have a table with about 20000 records in it called
Suburb. (It is a lookup table).

Running from another workstation:

select count(*) from Suburb

only takes about 60ms to return. How long does that take under the
BDE :)

>
> I am getting temporary directory using the API function GetTempPath.
>

That is fine

>
> I did what you suggest and it worked fine. I extract fbembed.dll

from Firebird-1.5.1.4481_embed_win32.zip, I rename it gds32.dll and
copied it into the folder of my application. I also copied the files

> ib_util.dll
> firebird.msg
> intl\fbintl.dll
> udf\fbudf.dll
> udf\ib_udf.dll
>
> But I'm not sure if firebird.msg is needed. Is it needed?
>

Maybe I didn't explain exactly what I got you to do. There is a
Firebird Server "built into" that version of gds32.dll. If you look
at the file size, it is probably about 1.5MB as opposed to the normal
one which is 350K. You can read the release notes in that folder to
understand exactly how it works. If Firebird has an error, then it is
going to want to convert that into a message, which is where
Firebird.msg is used. Now you understand that each client is also a
Firebird Server in its own right, it may explain why those files are
required on both client and server.

> Now I have only one problem (which I know :-) None of my PCs

(neither PC1 nor PC2) are connected to internet. They are only in a
LAN. When my application starts in PC2, when it executes the command
IBDataBase1.Connected:=True, with DataBaseName property set to
PC1:DataBaseAlias1 to conect to the first database in PC1, it opens
the windows dialog to connect to a Dial Up conection.

Probably a windows setting, check in internet explorer properties for
always dial a connection.

My advice to you would be to remove the whole idea that you need a
local cache unless there is an internet connection between the client
and the server workstations. It is likely that any performance issues
are because of poor architecture (because it is based on a desktop
database not a "real" database). I know it sounds a bit snobbish like
that, but do some performance testing in Firebird and you can see for
yourself whether you think the local cache is needed.

Adam