Re: Move from 5.01 to 7.21 4gl problem

David, I'm going to take a guess, because I don't know that this is your problem but it could be... There are about 6 paragraphs of explanatory material in this message, followed by two possible diagnoses for what's going on. And it is perfectly possible that neither diagnosis applies! Background: The 5.00 and later versions of ESQL/C have global cursors, whereas earlier versions (eg as used in the 4.1x I4GL products) had local cursors. Consider the following code in 2 I4GL source files: --file1.4gl DECLARE c_something CURSOR FOR ... --file2.4gl DECLARE c_something CURSOR FOR ... Under 4.1x, these cursors were distinct. By default, under the 5.00 and later versions of ESQL/C (and 6.0x I4GL uses 6.00 ESQL/C), these two cursors would be the same. Further, suppose the c_something in file1.4gl takes 6 input parameters and the one in file2.4gl takes 4. And suppose that the code tried to optimize on the declaration of the cursors so that the cursors were declared only once and then reused without being redeclared. If the execution sequence were DECLARE file1:c_something, OPEN file1:c_something, DECLARE file2:something, OPEN file2:c_something, (re)OPEN file1:c_something, then the re-open would fail because the actual cursor expected 4 parameters but got passed 6! Now, because I was aware of this problem (and because I'd written lots of code which used the cursor name c_select in every file on the understanding that the cursors were static, and no-one ever warned anybody it was likely to change so don't do it), I tried to ensure that the problem was avoided for I4GL 6.0x customers by using an algorithm to convert the cursor names in each file into a unique value. This is done by a hashing algorithm, and it is far from perfect. It also causes problems when you want to prepare an "UPDATE...WHERE CURRENT OF x" statement since the "x" you'd write isn't the "x" that the database sees (bug B31661). The CURSOR_NAME() function, a built-in, does the mapping for you, so you create the string as: LET updstr = "UPDATE ... WHERE CURRENT OF ", CURSOR_NAME("c_something") And that CURSOR_NAME call *MUST* be in the same file as the declare cursor statement -- it won't hash correctly if it isn't! Now, it is possible for the hashing algorithm to produce the same hashed name if two separate cursor names in the same source file are identical except for the last two letters and if the two names end with certain pairs of letters. This has been documented previously -- it should be in the IIUG archives (http://www.iiug.org), and possibly in the FAQ (same web site). If not, I'll dig the info out and get it reposted. Also, the c4gl compiler has an option -globcurs which suppresses the cursor name mangling algorithm (set C4GLFLAGS in the environment if you want it enabled on all compilations). If you use this, the cursor names are not altered from what you wrote, but every cursor name in every source file should be distinct from every other cursor name -- or, at least, you shouldn't try caching the cursors... Diagnosis: So, there 2 possible explanations for your problem: 1. You have two separate cursors in your file which hash to the same name, and you don't always declare those cursors before you do the OPEN. 2. You've somehow managed to get a conflict between source files, either because you are using -globcurs or by some more complex fluke (possibly involving you in pre-processing a non-I4GL file into a .4gl file before compiling the .4gl file, and removing the .4gl file before moving on to the next compilation). You can inspect for the first problem by looking at the .ec intermediate file (normally removed; add the -keep option to the c4gl command line) to see whether the declared cursor (or statement) names are duplicated. For the second problem, you'd have to do the same scan across all the source files. Or consider using some sort of monitor to track the names of cursors as they are used. The cursor names are transmitted to the engine, but getting the conversation logged and then interpreted in 6.0x and later isn't easy. Note that since your sample code seems to do DECLARE followed immediately and unconditionally by OPEN, I don't think this scenario should affect your code. Nevertheless, you may be running foul of it somehow... Yours verbosely, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> >From: "David J. Hinkle" <dhinkle@firstam.com> >Date: Thu, 5 Jun 1997 15:21:36 PST >X-Informix-List-Id: <list.14832> > >We are in the middle of a move from the Informix 5.01 engine to the >Informix 7.21.UD1 engine. We have a mamoth 4gl application that >needs to survive the move. Note that the 4gl application was >compiled using the 4.10.UD2 tools. Durring the acceptance testing of >the application running under 7.21 engine we have run into a strange >problem. A specific query works most of the time but fails every >once in a while with an error of: > >-254 Too many or too few host variables given. > >I've had our developer look into it and he is rather perplexed as >well. Below is a short message from him describing what he is doing: > > I have a table called t_table and it has 9 >variables in it. I wrote a 4gl program called get_t_table to get >information from the t_table and it look as follow: > >DEFINE > h_t_table RECORD > file_nbr LIKE t_table.file_nbr, > misc_seq LIKE t_table.misc_seq, > repo_id LIKE t_table.repo_id, > ident_nbr LIKE t_table.ident_nbr, > source LIKE burmsc.source, > rptd_mm LIKE t_table.rptd_mm, > rptd_yy LIKE burmsc.rptd_yy, > misc_text LIKE t_table.misc_text, > misc_text_len LIKE t_table.misc_text_len > END RECORD > > DECLARE tmp_cursor CURSOR FOR > SELECT file_nbr, misc_seq, repo_id, ident_nbr, source, rptd_mm, > rptd_yy, > misc_text, misc_text_len > INTO h_t_table.file_nbr, h_t_table.misc_seq, h_t_table.repo_id, > h_t_table.ident_nbr, > h_t_table.source, h_t_table.rptd_mm, h_t_table.rptd_yy, > h_t_table.misc_text, > h_t_table.misc_text_len > FROM t_table > WHERE file_nbr = g_curr_file_nbr > AND source = the_source > AND repo_id = the_repo_id > AND ident_nbr = the_ident_nbr> > OPEN tmp_cursor > ................ > >At run time sometime I get an error code -254 for OPEN tmp_cursor. Is >this ever happen to you? If it is. How can you fix it? > >Me back again, has anyone come across this kind of problem? What was >done to fix it. Is the 7.21.UD1 engine a reliable version, or do I >need to upgrade? Any tips will be greatly apreaciated because of >course management is breathing hard down my back to make this >happen!