Re: Stupid Debugger!!!

Wandering Child wrote: > I just spent the last 20 minutes going WTF to myself, but I finally > figured it out. > It seemed that a variable was changing values during a call to a > function. > > I'd confirm the value of everything passed into the function before I > called it, the typed in "wh" as soon as I got into the function > > sort of like this: > > |$wh > |some_func(f_order_det = RECORD, f_blah = 1, f_bah = 1, f_product = 32337) at line 3615 in > |crap.4gl > > Now, the value of product before calling this was 1200 > > I confirmed all variable types were compatible, even changing f_blah > from an Integer in the calling function, since it's a smallint in > some_func() and in the database. > > So, um, 32337 happens to be the same value as the 3rd element of > order_det. > > 1 happened to be right for f_blah and f_bah, but coincidentally they > are also the same values you'd find in the 1st 2 elements of > f_order_det > > And what was really making my head spin was that this seemed to be a > problem with the debugger, BUT the result seemed to be the same as it > was when running under 4Js BDL, which seemed less likely than being > struck by lightning while purchasing a winning lottery ticket. > > Damn! > > Now that I've got the plank out of my eye, I think I can get to the > splinter that's screwing us up. > > No question here other than does this problem exist in 9.4? > > Still on 7.3 here, but not for long First of all, I4GL 7.32 is the latest version - there is no I4GL 9.40. Secondly, if you write: DEFINE r RECORD a INT, b CHAR(3), c DATE END RECORD SELECT * INTO r.* FROM SomeWhere WHERE a = 13 CALL some_func(r.*) You can also write either: FUNCTION some_func(x, y, z) DEFINE x CHAR(10), y VARCHAR(255), z DATETIME YEAR TO SECOND Or: FUNCTION some_func(r) DEFINE r RECORD LIKE SomeWhere.* Or: FUNCTION some_func(r) DEFINE r RECORD a INT, b CHAR(3), c DATE END RECORD And in each case, three values are pushed onto the I4GL stack, and 3 values are popped off the stack, and type conversions occur as necessary (I'm assuming the table SomeWhere has 3 columns which are assignment compatible with INT, CHAR(3) and DATE). Note that the called function can be written to take either separate values or a record (or, if you want to get really fancy, a record and a separate value). -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/