At 11:53 PM 4/12/2004 +0000, you wrote:

> > When you say "execute stored procedure", what do you mean?
> > a) is it an executable stored procedure that returns a single row
>of
> > results following an EXECUTE PROCEDURE call?
> > or
> > b) is it a selectable stored procedure that includes a FOR
> > SELECT...INTO...DO...SUSPEND loop that returns a multi-row set
>upon a
> > SELECT <output list> FROM ... call?
> >
> > Or is it a SP that actually changes some data and also returns a
>multi-row
> > set?
> >
>
>It is procedure FOR SELECT ........ SUSPEND, only shows data without
>any update or insert. But takes data from second procedure and some
>tables.

This is not clear. Didn't you say that, if one instance of the procedure
was running in one window, another instance of the same procedure would
refuse to run in the second window, and return the bad block error?

> > Which problem? It seems you have at least two problems.
> >
>
>Generally - yes. But now I have few applications working on FB 1.0.3
>and without many hours of testing I don't want to change it to FB
>1.5. So, if I can resolve described problem, I will not chnge FB
>version now.

The first problem is to work out what the problem is.

> > -- The first is that on Firebird 1.0 you have some condition where
>a
> > running SP blocks another transaction from running the same SP and
> > apparently returns an error related to a bad block (parameter?
> > transaction?). Does it occur at Prepare time or at run-time? I
>would want
> > to enable an ib_monitordialog in the application, to see what is
>being
> > passed to and from the server when this error occurs.
> >
>
>At run-time. I don't know about this conditions,sorry. Can You tell
>me few words about it?

Presumably, before you run the stored procedure, your code checks to
determine whether the statement is prepared:

with MySPDataset do begin
if not Prepared then Prepare;

>I will try to observe in monitordialog what
>exactly is being passed to and from server.

The monitor will show you the contents of the parameter block that is
passed to the server at Prepare time; and it will subsequently show you
the values that are passed in the parameters when the statement is executed.

> > -- The second is that you have a connection-time problem with Fb
>1.5 and
> > the particular version of IBO that you are using. For Fb 1.5 you
>need at
> > least IBO version 4.3Aa or, alternatively, to set the
>OldParameterOrdering
> > parameter in firebird.conf to 1 (true). With IBO 4.3Aa and above,
> > connection time is extended by a few milliseconds (not seconds!!)
>while the
> > connection object runs a query to determine whether it is talking
>to a
> > v.1.5 database.
> >
>
>Wow, sounds good.But,in my world, things look different.

Hmm, I wonder whether you understood what I was saying there. IB and Fb
1.0 both have an old bug that causes stored procedure parameters to get
scrambled. IBO implemented a workaround for it long ago, and it is still
needed with IB and Fb 1.0.

In Fb 1.5, this old bug was fixed. That meant that IBO's in-built fix for
the bug would cause the (now correct) parameter ordering to get
scrambled. So changes were done in IBO v.4.3Aa, to detect a Fb 1.5
server. If you have IBO 4.3Aa or higher, you can now forget about
parameter ordering. If you have an IBO version 4.2.anything, or lower,
then for Fb 1.5, you must set OldParameterOrdering to 1 in firebird.conf.

Using IBO 4.3Aa or higher adds a slight delay (some milliseconds) to
connection time, because it performs a query to determine whether it is
connecting to a Fb 1.5 server. Does that make it clearer?

>I hope, that I'm doing mistakes. When I start application, and it is fully
>loaded
>into memory - now waits on keypress to start. I'm looking on Linux,
>monitoring when I can see ib process starting - and it is usually 13-
>17 seconds on FB 1.0.3 CS. When I delete from xinetd definition
>lines (LOG ON SUCCESS...LOG ON FAILURE ..) this time is less, but
>not milliseconds - about 7-8 seconds app is spending. So, it is
>something strange, comparing to Your time. I can't find a reason.

I think they are unrelated.

>With IB 1.5 I will try OldParameterOrdering. Thanks.

That was not intended as a hint to make connection faster. It was stated
as a fact that you need to know about, in order to use old IBO versions
with Firebird 1.5.

> > Do you understand also that the Fb 1.5 Windows client is named
>fbclient.dll
> > and that you need to get the Windows kit and install the correct
> > client? For IBO, unless you perform the appropriate changes in
>your
> > software and recompile your application, you will need to rename
>this
> > client as gds32.dll and install it on all of the clients in their %
>system%
> > directory.
>
>Sorry, if I can understand - this means, that compilation of my app
>depends on gds32.dll version which I have instaled in my computer???

No. It means that, if you are using Firebird 1.5, and you don't know how
to make an IBO app work with a client named fbclient.dll, then at the very
least you will have to rename a copy of fbclient.dll, from a Windows kit
for the server version that matches YOUR server. This is because, by
default, IBO loads a client library named gds32.dll from the %system% dir.

You don't need to recompile your application *unless* you decide to make
the necessary changes to use the client library under its original name.

Now, assuming that all of your client machines have gds32.dll and are
loading it from %system%, you must ensure that each client machine has the
correct version of gds32.dll. The same thing applies, even if you are
running Fb 1.0 -- where you are seeing your first problem. Make sure that
the client machines have the correct gds32.dll for the version of the Fb
server that they are connecting to. An old gds32.dll from IB 6, or IB 5.x,
or from an older Fb 1.0 beta, will not do.

./hb