Re: What is error -424 in ESQL/C

>Date: Tue, 28 Apr 92 13:42:16 -0400 >Message-Id: <9204281742.AA09145@relay1.UU.NET> >Subject: Re: What is error -424 in ESQL/C > > ... > >Is there any way to free the cursor name when dynamically executing >SQL statements (using prepare, describe, and declare)? What exactly >happens when a cursor is closed and a sqlda structure freed? What >would happen if I freed a cursor that has been prepared? (The Version >4.00 book expressly forbids this) The FREE I am referring to is "EXEC SQL FREE cursor_id;" or "$FREE cursor_id;", not your casual free() as in malloc and friends. There are several possible scenarios to consider: Scenario A: EXEC SQL DECLARE c_scenario_a CURSOR FOR SELECT A FROM B; After using OPEN, FETCH and CLOSE on this, you can use: EXEC SQL FREE c_scenario_a; This will release any temporary resource associated with this cursor in both the Engine and the front end interface code. Scenario B: EXEC SQL PREPARE s_scenario_b FROM "SELECT * FROM Sysindexes"; EXEC SQL DESCRIBE s_scenario_b INTO sqlda; EXEC SQL DECLARE c_scenario_b CURSOR FOR s_scenario_b; After fixing up sqlda and using OPEN, FETCH, CLOSE, you can use: EXEC SQL FREE s_scenario_b; After you have freed any memory allocated when fixing up sqlda, you can also use: free(sqlda); Scenario C: !!!BUGGY CODE!!! EXEC SQL PREPARE s_scenario_c FROM "SELECT * FROM Sysindexes"; EXEC SQL DESCRIBE s_scenario_c INTO sqlda; EXEC SQL DECLARE c_scenario_c CURSOR FOR s_scenario_c; After fixing up sqlda and using OPEN, FETCH, CLOSE, you then mistakenly use: EXEC SQL FREE c_scenario_c; At this point, the system is apt to get its memory allocation in a mess. Probably, but by no means certainly, most of the temporary info to do with statement s_scenario_c is probably not released. However, it is a fair bet that subsequently executing: EXEC SQL FREE s_scenario_c; would lead to worse trouble -- probably re-releasing space that is already released, and leading to havoc in the memory allocation system. That is why you are strongly discouraged from making the mistake. In Scenario A, there is no explicit statement ID to release, so you must release the cursor ID; in Scenarios B and C, you should release the statement ID, not the cursor ID. All the above applies to Version 4.10 and earlier. With Version 5.0, things are slightly more complicated again. The basics remain the same (so all the above remains accurate), but there are additional features for playing with descriptors in the language. These are GET DESCRIPTOR, SET DESCRIPTOR, ALLOCATE DESCRIPTOR, and DEALLOCATE DESCRIPTOR. I can't give a useful explanation of these -- I haven't worked it out yet (mainly lack of time). Additionally, you can use character string variables in place of the statement and cursor IDs used above. Yours, Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>