---------- Original Message -----------
From: "arda" <atuncce...@duzen.com.tr>
> I have great difficulty when I need to change a stored procedure or 
> table structure. I receive "object in use" errors and can't do 
> anything at day time. I need to wait till about midnight and 
> disconnect all clients. What could I do if the applications was used 
> 24 hours a day continuously?
> 
> "Object in use" errors also block me when I need to do some index 
> alterations. It would be great if I could modify or drop the index at daytime.
> 
> If it's possible to accept the changes even if the object is in 
> use(stored procedure), it would make life much easier for developers 
> like me.
> 
> Maybe the database can store the versions of stored procedures 
> transparently? After modification, the object which was in used called 
> next time, the client could use the modified version. And after a 
> backup-restore, the old versions can be cleaned up?
------- End of Original Message -------

I use 2.1, with connection-pooled app-server (there are always connections, and 
some of my stuff involves long-running transactions, too.) Anecdotal:

When using Classic, my only problem with doing DDL during the day was that 
Classic would 'cache' the DDL, and there were situations where I really wanted 
the update to apply everywhere immediately. I'd have to force disconnects to 
clear the cache.

I've also occasionally had problems modifying triggers/procedures during the 
day, and then seeing that some connections are getting "blob not found" errors.

With SuperServer, I've had issues re-indexing during the day; it's fine, unless 
a stored proc is called during the time that indices are de-activated; it seems 
(!) to cache the modified plan (without index), and even after the indexing 
completes, similar stored procedure calls (possibly because of the connection-
pools, calls are often on the same connection) may skip using the index despite 
its availability. I have to disconnect and reconnect them, and then things 
start flowing nicely. But FB doesn't prevent me from making the change. 

In fact, if I have a long-running query using an index, and I decide to 
deactivate/reactivate it? I don't get an error -- but the long-running query 
does (index unexpectedly deleted). Again, I'm not prevented.

I've not had chronic problems with "object is in use" since FB 1.x, and being 
unable to touch FK constraints/indices/view-definitions during the day (again, 
perpetual client connections.) I believe that particular problem was resolved 
in 2.x?

-Philip

Reply via email to