--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

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

It was exactly what i said in message 30120, but you probably
ignored it.

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

Yes, i'm using FB 1.5 Final on Linux, and the OldParameterOrdering
is set to True, because i couldn't ship (after more than 1 month of
tests and waiting for answers that never comes) a version of my
application with IBO 4.3 to my customers and disable this flag.

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

Do you mean Jason is the only person in the world that can solve IBO
problems? You are scaring me...
So if Jason get sick, or something happens to him, i will have to
wait 4 minutes to open my application to the rest of my live? ;-)
I wasn't expecting an imediate solution, but 'we will look at it
some day' could help to control my anxiety.

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

But there is. If you look at the 'Files' section of this group,
there is a test case called IBOTest.zip showing it. This test was
posted on '07/08/2003' and the problem isn't solved until now. I
sent another test case for Jason some weeks ago and all i had
was 'It is something related to the JoinLinks property'. It's not
enought for me. The problem is still there, but luckly (!) this case
had an workaround (that i had to discover by myself and change lots
of forms manually).

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

The first time i posted the issue above, i was also ignored.
Probably because, as you say below, it 'doesn't appear to affect
others'. But after i 'made threats and got insulting', Jason looked
at it and found something wrong in the unit IBODataSet.pas
(procedure CheckFieldCompatibility) and sent me a version that
solved my problem. Maybe 'make threats and got insulting' is the way
to get some attention here. It's happening just now...

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

What is your criteria to define a bug? It have to affect thousands
of users before? Just because it affects just one damn user you
think you can imediatelly classify this user as an idiot and ignore
him? Maybe i am the first using some set of attributes together,
that is causing the bug.

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

And if Jason is traveling or busy, god help me?

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

Excuse me, but i pay a fee yearly to renew my IBO licenses. If this
license doesn't include the support for the product i'm buying and i
am at my own risk, you should state it very clear before i send my
credit card number.

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

I am assigning the SchemaChacheDir just to ensure that it's empty.
Same as in the DLL. The main application SchemaCacheDir is always
empty.
Look at this code. I create a new project from scratch, add a button
in the form, and:

procedure TForm1.Button1Click(Sender: TObject);
var
x: TIBODatabase;
y: TIBOQuery;
begin
x := TIBODatabase.Create(Self);
x.DatabaseName := 'xxx.xxx.xxx.xxx:tecotton'; // xxx is the remote
server ip address
x.LoginPrompt := False;
x.Username := 'SYSDBA';
x.Password := 'masterkey';
x.SQLRole := 'publico';
x.SchemaCacheDir := '';
x.Connect;

y := TIBOQuery.Create(Self);
y.RequestLive := True;
y.SQL.Text := 'select * from emp1'; // the table has just 1 record
y.Open;

ShowMessage('DataSet Opened');
end;

Run and click the button. Compiled with IBO 4.2 (15 sec) and with
IBO 4.3 (4 minutes). I can send the executables.
Am i doing something freak or not usual here??? The same results
running on several remote servers.
Maybe my report seems inconsistent because i tested all
possibilities before send the question to the support, and my mind
was not very clean the moment i typed the text, but i think the code
above is enought to show what i am doing.

> Have you checked
> the client's hard drive to see whether there are any schema cache

tables

> there?

Yes, I checked. In the example above it does not create any schema
table anywhere. I searched for 'ClientSchemaVer.IBO' and it doesn't
create the table (you will probably say here: so the delay is not
related to the schema). And i say: If i change the SchemaCacheDir
to 'c:\temp', it takes 4 minutes to open at first time, and 15
seconds in the next times.

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

Yes, there is a IBO$SCHEMA_VERSION there. But it have been there
since oldest versions of IBO, and never affected IBO 4.2.

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

I am almost sure i did this based on some messages found in this
group archive, probably oriented by Jason. I will try to find their
numbers. Anyway, it worked without problems until IBO 4.3.
But this is a good example of what i am talking about. You said 'You
can't to ... because ...' but didn't provide anything usefull that
could help me to find the right way. An advice, a link, a manual, a
reference, nothing.

> It seems quite likely, on reading this, that the sources of your

problems

> are not where you think they are.

Maybe. But they are related to IBO, and the technical staff of IBO
is the only source i know to ask for help. If you don't help, i
don't where else to search.

> Helen

Fabiano