Feature Requests

John writes in X-Informix-List-Id: <list.356> >Sigh. I can't figure out how to explain this problem in a simple, >obvious way. ESQL/C currently restricts cursor names and >statement-ids to hard-wired constants. This is fine if you know >what SQL you are going to run into at compile time, but this >restriction is a big problem if you don't know what SQL is coming at >you. If you want to prepare 10 statements and hold them for later >execution, you have to write 10 separate statements like > etc Thanks John, I understand the requirement now. Certainly it would be a nice facility to have but not being a C person I'm not sure how many users actually require it. Have you raised it as a feature request? On the subject of feature requests I have three which I am thinking of raising. Comments from Informix and others welcome. 1. Ability in 4gl to define the size of an array at run-time. It can be done but it would be a nice if it was part of the language. 2. When you open a cursor in 4GL it would be nice if Informix would place an estimate of the number of rows that will be returned in SQLCA ERRCODE[3] before you do any fetches. With the above you could then declare a cursor, open it create an array of the right size and process the rows. I'm certain that the information is available in the system because I-SQL forms presents the number found when you do a query on the screen and I doubt that SQL is doing the select twice (Once with select count(*)). Alternatively is there a function (Undocumented of course) that will return the information. 3. Having persistent cursors in v4 is great for doing batch update runs where you are updating set of rows in detail tables after fetching a master row from the master table. But I would like to see an extension to this 'persistent locks'. Every so often you want to be able to complete a transaction but not lose the lock on the master row. Eg in stock control, storing/loading applications. The idea is that you have a number of items you want to store in a single location. Each store action is a seperate transaction but you are for a time working with the same location. While you are working with that location you want to stop anybody else updating the location information. >From a practical point you would require a FETCH WITH HOLD within a cursor with hold, the commit would act precisely as it does now except it would not release locks gained by a fetch with hold. The lock would be released on next fetch or close cursor at standard engine/online cursor stability isolation level or at close cursor at online repeatable read isolation level. At the moment you need to regain the lock in a new transaction immediately after the commit but this still leaves a small window where another user can grab the lock so you have to write code to cope with that happening. With the above suggestion it would be unnecessary. Cheers, Jim -------------------------------------------------------------------- Name: Jim Gordon Internet: jgordon@ssf-sys.DHL.COM Company: DHL Systems Inc Phone: (415) 358-5911 Address: 1700 S. Amphlett Blvd. Fax: (415) 571-6429 San Mateo, CA 94402 --------------------------------------------------------------------