Adam (and David):

I checked in internet explorer properties and, as usual, you were right Adam. The reason why my application opens the windows dialog to connect to a Dial Up conection was a Windows setting.

The main reason because of which I use a temporary database is the following. I have many cases of "master-detail" tables, for example a customer table and another table which has data of employees of each customer. When a user wants to modify the data of a customer, the application uses a temporary table in which it copies the registers of the employee table corresponding to that customer. Then it shows a form with the customer data that contains a grid with the employee registers. The DataSource.DataSet property of this grid is the temporary table. When the user clicks the "save" button, the application, copies the registers of the temporary table to the not temporary employee table.

I know that "Migration from a BDE/ISAM design to an RDBMS design is more involved than putting the RDBMS tables behind the old structures", as David said. I have an application which is installed in many users and I'm migrating it to FireBird step by step. I know that I have to eliminate every TTable but I'm doing it step by step. By the moment I changed some of the TTables to querys, such as the LookupCombos and many others. But I didn't change (by the moment) the temporary tables I mentioned in this paragraph. These are tables which always have only a few records and I thought that changing them would not be so important. But, as you can see, I'm a newbie in RDBMS, and so I admit I may be wrong. What do you think of this?

Adam, you said that temporary tables is more justified if I have customers that need to use internet connection between the client
and the server workstations. In a few cases this is just the case. I have a few customers that have two or more physical diferent places connected via internet and they use my application with one server in one of these places and clients in different places.

Another thing is related to performance. As you said, and as I expected, my application with FireBird should have much better performance than with dBase and BDE. But the fact it's just the opposite. May be because of the way I do some things, like the way I manage my "master-detail" relationships I explained before. A comment that perhaps is important is that I use a lot of CommitRetaining. I believe I remember reading in this forum that using Commit has better performance than using CommitRetaining. I would be very grateful if you give me some advice on what should I check to improve the performance of my application.

I repeat again I really thank you very much for your help.

Gustavo
----- Mensaje original -----
De: Adam
Para: firebird-support@yahoogroups.com
Enviado: Martes, 21 de Junio de 2005 22:51
Asunto: [firebird-support] Re: Client in FireBird

--- 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






++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Visit http://firebird.sourceforge.net and click the Resources item
on the main (top) menu. Try Knowledgebase and FAQ links !

Also search the knowledgebases at http://www.ibphoenix.com

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++




------------------------------------------------------------------------------
Yahoo! Groups Links

a.. To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

b.. To unsubscribe from this group, send an email to:
firebird-support-unsubscribe@yahoogroups.com

c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.




[Non-text portions of this message have been removed]