Commented by: @dyemanov

Perhaps you use a nowait transaction, hence the result?

Commented by: @helebor

Also check that the kit you downloaded was RC3. For a few days, the links to the Linux packages from our website were pointing to the RC2 kits. :-(

Commented by: @kattunga

yes, I use nowait transactions.
Why this could be a problem? The transaction that use the procedure was commited some minutes ago

Commented by: @kattunga

I'm using latest daily snapshot now, also I tested it with RC2 and RC3

Commented by: @dyemanov

Are you sure the object is not really in use? Commit of the transaction is not a guarantee. Also all the queries that [directly or indirectly] use that procedure should be destroyed.

Commented by: @AlexPeshkoff

Christian, can you provide a test case?

Commented by: @kattunga

I attached a test database.

Open it from 2 different connections (in my case I use IBExpert Personal Edition)

In connection 1 do:
SELECT * FROM NEW_PROCEDURE
then commit the transaction (but not close connection)

In connection 2 try to modify the string that procedure return
When you try to commit the change it will raise the error object is in use

The two connections are open as:
isc_tpb_read_committed
isc_tpb_rec_version
isc_tpb_nowait

Commented by: @kattunga

Dmitry, exactlly the same test in Firebird 2.1.3 SS works fine.
In 2.1.3 CS works fine too, but you need to reconnect the other connections to see the changes (because metadata cache its not shared).
In 2.5 CS raise this exception, I didn't test 2.5 SS

If I'm not wrong, 2.5 CS have metadata cache shared between connections so it would work as FB SS, couldn't be the problem due this new feature?

Commented by: @AlexPeshkoff

Christian, looks like this is something client-s[ecific.
With isql I can't reproduce an issue.

Commented by: @kattunga

Alexander, mi enviroment is:

Server is 2.5 CS LINUX Ubuntu Lucid

Client is fbclient 2.5 WINDOWS 32 bits, I can reproduce it from two diferent tools, IBExpert and a Delphi application that I programmed.

Commented by: @dyemanov

2.5 CS doesn't have a shared metadata cache, so it should behave identically to v2.1. The only difference is that you're no longer required to reconnect in order to see the new version of the procedure.

Commented by: Hilmar Brodner (syn)

We have exactly the same problem.

We had a discussion about this in CORE2613 and there we were told that procedures could be changed even if they are not yet committed.

The comment above:
"Are you sure the object is not really in use? Commit of the transaction is not a guarantee. Also all the queries that [directly or indirectly] use that procedure should be destroyed. "
Dmitry Yemanov added a comment - 13/Aug/10 07:08 AM

pretty much scares us as in CORE2613 we were told

"you can alter/drop procedure while it's used by someone else. This was disabled in v2.0.0 (thus rejecting modifications) and re-enabled in v2.0.1."
Dmitry Yemanov added a comment - 01/Sep/09 11:26 PM

With SS you don't get this problem. It only appears to happen with CS and SCS.

We waited for FB2.5 for over a year to be able to continue to work like we did under FB1.5 as with this we were told that we can change Views, Triggers and Procedures at runtime. This now does not seem to be the case.

Commented by: @kattunga

Dmitry Yemanov, Alexander Peshkov

Checking my reported bugs I found this one.
I was really an idiot, I was using nowait transactions to alter procedures.

Yes, I know this was your firs question. -> "Perhaps you use a nowait transaction, hence the result?"
Sorry.

This bug should be closed.