At 01:06 PM 18/03/2004 +0000, you wrote:

> > > It was present in IBO 4.2, as long as you had a value in the
> > SchemaCacheDir
> > > property of your TIB_Connection. Just delete it.
>
>You are wrong. This delay is not present in IBO 4.2, filling
>SchemaCacheDir or not. At least for me (i just use TIBOQueries in my
>application).
>In IBO 4.3 this delay is always present, SchemaCacheDir filled or
>not.

Here is all I can offer, on your theory that loading the schema is a new
thing in v.4.3. To me, it is not new. It has been happening with all of
the 4.2 versions I've been working with for as long as I recall. I thought
perhaps you were loading the SchemaCache. All you needed to say was that
you weren't using the SchemaCache.

I notice no difference in connection time at all, between the two versions.

Are you certain it is the metadata loading that is causing your delay? One
extra connection that 4.3 has, that 4.2 had not, is a preliminary query on
some tables, to determine whether you are running Firebird 1.5. This
addresses the matter of OldParameterOrdering, which should now be
configured OFF.

Are you using Firebird 1.5 and, if so, do you still have
OldParameterOrdering set to true?

>Like many other times, i am alone with my IBO problems, waiting for
>an answer that never comes... If i just received a private e-mail
>saying 'wait, we are looking at your problem' i wouldn't be so upset.

That is somewhat impossible at the moment. You posted your initial message
March 16, two days after Jason left for a conference in Europe. The date
on this message is March 18. Jason is still in Europe.

I answered your question because I thought it might help. It didn't
help. I, for one, cannot reproduce your problem. Apparently nobody else
could think of anything either. Luckily, in this list, there are usually
people who can suggest things and people do solve their problems. This
time there wasn't.

>It's getting usual: I post a question, somebody answer with some
>trick that doesn't work, or saying that i'm doing something unusual
>without explaining why i should not do that or providing an
>alternative, and, at the end, here i am alone with my problems,
>trying to imagine some excuse to justify to my customers some things
>like why the NEW version of my application takes 4 minutes to open
>while the old version takes 10 seconds (good improvement, huh?), why
>a record vanish in the air when he click on the 'Post' button when
>he typed something in a blob field (this is an old request, caused
>by a bug in the join links property

I've never encountered a bug in the joinlinks property. I've encountered
quite a few people who don't use it properly. The same with KeyLinks. And
that can cause things to appear to vanish from the buffers.

>, that was never solved and
>forced me to change about 200 forms in my application by hand), why
>my application raises an error when compiled with the new version of
>IBO (this problem was solved just after i asked my money back),

Coincidence. I've never known Jason to be responsive to stand-over
tactics. He will stay up all night to fix something that's a problem for
someone - just because it's a problem, not because people make threats or
get insulting. And he's always willing to refund your money if you decide
you don't want IBO after all.

>why
>a TIBODatabase inside a DLL loads the schema again even if the
>schemacachedir is the same of the main application (see below), and
>so on...

So why do you think you are having these problems, when they don't appear
to affect others? If you have a TIBODatabase instantiating itself in a
DLL, it's going to do all of the things that a TIBODatabase has to do.

>Maybe i am asking in the wrong place? Is this group just for idiot
>questions, like 'how do i select all records from a table'? Or am i
>expecting more from IBO support than i can have?

That could be the nub of the question. What do you believe you are
entitled to?

>If so, what can i expect from your support team? Just usual questions?
>Normally i solve my usual questions before asking them.

Ask questions...if other users can't help, Jason takes it up.

>It's the last time i renew my IBO license. I will try other
>alternatives from now. I can't accept this kind of support of a paid
>product. You are not making me a favor, i am paying for support, and
>i'm not getting it.

I can't comment on that, since I don't know who Jason has on paid support
contracts unless he asks me to take care of one...you have never been on my
"list".

>DLL: I have another bug for you ignore: After the first 4 minutes
>delay, when i am connected and everything is going fine (fine???) my
>application call a DLL, and this DLL has a TIBODatabase inside it.
>After assign the main TIBODatabase.dbHandle to the DLL
>TIBODatabase.dbHandleShared and after assign the main
>TIBODatabase.SchemaCacheDir to the DLL TIBODatabase.SchemaCacheDir,
>the first dataset of the dll takes 4 minutes to open too... (the
>same happens if SchemaCacheDir is empty or not).

In the first place, if you are *assigning* a SchemaCache Dir, you are
causing IBO to build a Schema cache that you apparently don't
want...different parts of your report seem inconsistent. Have you checked
the client's hard drive to see whether there are any schema cache tables
there? Have you checked the database to see whether there is a schema
table there? It has a name something similar to "IBO$SCHEMA". If you don't
want schema caching, disable it! Check your DFMs, too, to find out whether
there is schema caching that you forgot about.

All that aside, this technique sounds all wrong to me. I'm sure you can't
share a dbHandle between two executables. DbHandleShared is for a
TIB_Connection to share a DBhandle with a BDE connection, inside the *same*
application module.

It seems quite likely, on reading this, that the sources of your problems
are not where you think they are.

Helen