Re: Not calling CLOSE when fi

>From: billy.wheeler@digitec.co.za (Billy Wheeler) >Subject: Not calling CLOSE when fi >Date: 5 May 94 11:06:00 GMT >X-Informix-List-Id: <news.6618> > >To: bmaccion@promus.com >who wrote: > >BM> I'm maintaining some informix C code and have noticed >> that there are a lot of places where the programmer didn't >> call a CLOSE after he/she was done with the cursor. The >> next time the routine is called I assume that Informix >> does the close first and then the open as coded, however > >Yes. Yes, subject to a number of provisos, the principal one being that if the database is MODE ANSI, then you must close it before re-opening it. You also can't close an unopened cursor (any type of DB), and you can't close an already closed cursor in a MODE ANSI database. This is basically rehashing material from the 4.10 release notes. >BM> Sooo, with say 100 or so extra cursors hanging around open >> is there any performance to be gained by closing them? > >NO! I went on an Informix Optimisation course, and we were clearly told that >CLOSE then OPEN is actually slower than OPEN implying the CLOSE. It depends on what your performance measurements are. There used to be a limit of 64 statements and cursors; this was increased to 256 in 4.10 and unlimited in 5.00. Thus, the correct operation of a program may depend on closing and freeing cursors which are not in use. More importantly, as someone else pointed out, closing and freeing cursors (and statements) does release memory for reuse, so if memory on your machine is an issue, then closing them (and freeing them) is a good idea. However, it is undoubtedly true that an CLOSE followed by an OPEN does require two messages to be sent to the engine, which takes longer than simply doing OPEN. However, except in benchmark situations or on overloaded machines, I doubt if you would notice the difference. As a general rule, it is a good idea to close what you open, and to free what you allocate. If nothing else, it shows that you know what resources are in use by your program. FYI: with the 6.00 Engines and things like shared memory connectivity, if your program does not explicitly close the database, the thread serving the program will not notice for a noticable time that the program is no longer there. This can lead to problems if you expect to be able to drop the database (a recurring problem for our QA tests), or if you need to get exclusive access to the database. If the database was opened by the I4GL compilers, we have to close it before we exit to ensure we don't retain a connection for longer than it takes to run the program it just compiled. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> ,