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