>>teste.gdb took about 3m30s

Is your server is running a version of Windows that considers "GDB" a
system file? If so this would easily explain the time this takes to
open, as Windows will make a copy of the file first. Change to FDB or
shut off "System Restore" in Windows and see what happens.

--- In IBObjects@yahoogroups.com, "fabiano_bonin" <fabiano@p...> wrote:
> > 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.