> Of course, this form is opening
> one dataset. In the worst case, you have a main form that is

starting up

> with active datasets (that terrible old BDE default) and a lot of

them.

As i said before, i am sure my application is openning just one
dataset. The example i posted in the previous message is taking
about 4 minutes to connect, and the code you see there is the only
code of that application.

Anyway, in the link below are the results i obtained using YOUR test
application:
http://www.personalsoft.com.br/dataset_open_log.zip

First i connected to employee.fdb (table employee) and then i
connected to teste.gdb (table emp1), both on the same remote server,
using IBO 4.3Aa.
Next, i connected to employee.fdb (table employee) and then i
connected to teste.gdb (table emp1), both on the same remote server,
using IBO 4.2Gc.

IBO 4.3 Aa
Employee.fdb database took about 30s to open the query, and
teste.gdb took about 3m30s to do the same (probably because it's
metadata is much more complex).

IBO 4.2 Gc
Employee.fdb database took about 15s to open the query, and
teste.gdb took about 15s also to do the same

COMPARISION
Comparing the log files using your diff tool, you can see in the IBO
4.3 logs more queries related to the schema than in IBO 4.2, and the
open times reflects what i am talking about, specially the last
query, that takes 3 minutes in teste.gdb with IBO 4.3.

It i am not wrong, these queries shouldn't be there, because
SchemaCacheDir is empty in your application. Even in IBO 4.2,
although the open time is faster, i see some queries used to extract
metadata. They are in less number than IBO 4.3, but they shouldn't
be there anyway.

Let me know if the steps shown in my IBO 4.3 logs are different of
yours, because it should be identical. The only difference between
the IBO version in my computer (4.3Aa) and the out-of-the box
version, is the change in the procedure
TIBODataSet.CheckFieldCompatibility that Jason sent to me to solve
another bug that was affecting me. Below is the code:



procedure TIBODataSet.CheckFieldCompatibility( Field: TField;
FieldDef: TFieldDef );
begin
if Field.DataType = ftFloat then Field.Size := 0;
if ( Field.DataType = ftBCD ) {and ( Field.Size = 8 )} {Cover a
past bug} then
begin
Field.Size := FieldDef.Size;
if Field is TBCDField then
with Field as TBCDField do
Precision := FieldDef.Precision;
end;
if FieldDef.DataType = ftFloat then FieldDef.Size := 0;
if (( Field.DataType = ftLargeInt ) and ( FieldDef.DataType =
ftInteger )) or
(( Field.DataType = ftInteger ) and ( FieldDef.DataType =
ftLargeInt )) or
(( Field.DataType = ftBCD ) and ( FieldDef.DataType =
ftLargeInt )) or
(( Field.DataType = ftBCD ) and ( FieldDef.DataType =
ftInteger )) or
(( Field.DataType = ftBCD ) and ( FieldDef.DataType =
ftFloat )) or
(( Field.DataType = ftFloat ) and ( FieldDef.DataType =
ftLargeInt )) or
(( Field.DataType = ftFloat ) and ( FieldDef.DataType =
ftInteger )) or
(( Field.DataType = ftFloat ) and ( FieldDef.DataType =
ftBCD )) then
//Allow this type conversion to pass.
else
if ( Field.DataType = ftString ) and ( FieldDef.DataType =
ftMemo ) then
//Allow this type conversion to pass.
begin
// Make sure it is really a string though.
if Field.DataSize >= MaxWord then
DatabaseErrorFmt( SFieldSizeMismatch,
[Field.DisplayName, Field.Size,
FieldDef.Size],
Self );
end
else
inherited CheckFieldCompatibility( Field, FieldDef );
end;

Jason -> Replace this method, rebuild and let me know how it goes
from there.

> BeyondCompare or another Diff tool. You will soon see why table

objects

> eat so much bandwidth compared to query objects.

Just to say, i don't use a TTable object anywhere in my application
since 3 or 4 years ago.

Fabiano.