Re: 4GL Cursors again

afalout@zg.tel.hr (Andrej Falout) wrote: :Nils.Myklebust@idg.no (Nils Myklebust) wrote: : :>afalout@zg.tel.hr (Andrej Falout) wrote: :> :(...big snip...) : :>:I want to avoid using FREE. I still have to support some V2 4gl :>:compilers that does not have them. I can use only CLOSE. :> :>I think you have hit an absolute limit unless it helps to increase the :>max. number of files each process can have open. : :Ooops, this is somethig new to me. Process = engine? Files=File system :files like SE *.DAT & *.IDX? Please elaborate.... Every time you open a new cursor in an SE database the server will have to open at least two files (the .DAT and .IDX files). It *might* therefore help to increase the maximum number of files each user can have open. You may then also have to increase the systemwide maximum number of open files. I no longer remember for sure what the kernel tuning variables are named, but they are documented. You may have to change several of them. However I also think there is a limit in the engine to how many cursors can be prepared/declared simultaneously. It's more likely that you have hit this limit as a simple close of a cursor also ought to close the files. (I assume you do close your cursors. If not you should start to do that.) :>Otherwise the only solution I can see given your limits (not using :>free) is to create a function you can call that will create the :>different statements in a char variable and use the same :>prepare/declare to create the cursor as you need it. In this case you :>can open the same cursor (one with the same name) in different :>functions and in reality have totaly unrelated sql statements behind :>it. It will *not* be nice (very bad programming practice), it will be :>slow, but it should work. Of course you will have to be extremely :>carefull not calling this common function while a cursor based on it :>is open. You may need more than one such function to be able to avoide :>that. : :Meaning I will have to prepare+declate+fetch everything, since simple :"select * into var.* from x" directly in 4gl code is also a statement :to the engine. Or not? When we used these early versions of the Informix engines we found that if we replaced cursors with simple select statements (with into variable) we got rid of the problems you have. (I hope the above is only an example. Don't ever use select *. It creates a lot of problems when you need to change the database.) :>Another thing we did when we had this problem was to replace several :>cursors with singleton sql statements where that was possible. It's :>slow, but again it made the application work. :> :>I hope your customers will soon be able to upgrade to some later :>engine. The world will be very much easier for you and them when they :>can. : :I heard that one before, somewhere...., don't remember where. In this :case, and not only this, it is my fault. I am unable to explane to :them why 386 with 8 MB ram and 2*200MB HD and SE 2.x is unable to do :the same job it was able to do for 7 years. It can't be the same job. If it was you wouldn't have to change the application. That's the key thing you have to explain. The application have come to the limit of their current hardware and database solution. It's of course unfortunate that they will today typically need at least 16 Mb (for SE and 1 to 2 users) and usually 32 Mb on a pentium machine with at least 1 Gb disk to do more or less the same as the above 386 can still do. Although they don't need it, it will run substantially faster, and should cost less than that 386 machine did 7 years ago. There are substantial expenses for OS and DB upgrades as well though, so I can understand the customers reluctanse. You migth save money by installing Linux instead of SCO. It may however require more experimentation than it's worth. To me it sounds like you are in a size bracket (size of database, number of users) where the combination of Unix on PC and Informix databases now are less competitive than they should have been. From your other posts I see you are also playing with 4GL on Windows which might have been a solution. : They don't want it any :faster. They don't want more users, or app's or anything. They have :another server with OL7.x, and to them is all the same, ok, little :(sic!) faster. They _only_ want me to keep supporting my own app. :#%&$#%$&!!!!!!! May be you have to bite the bullet and do some fundamental changes if you want to remain in the market. In my opinon it's sad that Informix haven't enabled us to continue to support this low end market effectively with 4GL applications. A reasonably priced Linux port might have helped. Running on Linux *may* be a solution for you anyway? Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org