Re: Issue with legacy informix driver

In article <3587BE7D.423D@earthlink.net>, jleffler@earthlink.net wrote: > > mbristol@my-dejanews.com wrote: > > davek@summitdata.com (David Kosenko) wrote: > > > mbristol@my-dejanews.com offerred: > > > +When the application calls EXEC SQL DESCRIBE stmt INTO sqldba_p; I'm seeing > > > +the resultant structure alter the column datatypes (sqlba_p=>sqltype) to > > > +something other than that which I'd expect. I'm seeing columns created in > > > +the database (and viewable in informix.syscolumns.coltype ...) as REAL, > > > +FLOAT, and DECIMAL all returned to me with a DECIMAL type attached to them. > > > > > > It would help to see the actual query you are applying the describe to, but > > > I'll guess that you are doing some math or aggregate calculation on the REAL > > > and FLOAT columns in the query? > > > > Nope, its just any typical query. [...] I've discovered something else > > though (you know how the in-your-face stuff is ignored unless you stop for a > > while and come back to it). > > > > This behavior only shows up when crossing a platform boundary into or out of > > DEC4.0 land, i.e. a driver built on DEC 4.0d accessing a database on Solaris > > 2.6, SunOS 4.14 or HP-UX 10.20 sees the sqltype as SQLDECIMAL, while the same > > code running against a native 4.0d database works fine . [ ... ] > > OK, there's a simple explanation. Different CPU types use different > formats for C double and float (SQL FLOAT and SMALLFLOAT) values. When > you > communicate across machine types, Informix prefers to get the data > across > coherently, and the way it does that is to convert to DECIMAL -- it is > generally more accurate (and certainly easier) than trying to convert > between > different native floating-point formats Yup! I caught on to that soon after I sent this message because I found a #define for SQLNETFLT in the compiled .c code esql puts out! It made me wonder so I did some more investigation. I noticed that my scale always whoed up as (- 1) because sqlda_p->sqllen value is set to ##FF which this occurs. I coulld test externally for it just by validating that number, but it took me a while to realize that the first to byte represetn the initial length! > > If you had read your manuals excruciatingly carefully and if you had > monitored > the right part of the SQLCA warning structure immediately after > connecting to > the database, then you'd know that this conversion was going on because > Informix > sets a flag to warn you that it will happen. > Yup - sqlwarn4 after a connect is set to "W". That's buried deep! I never even thought of looking at the sqlca structure. This will do great. I'm still not sure what one might use SQLNETFLT for, because the bit it references is not set even though it looks like the condition it is meant to handle is present. Maybe that is related to that Environment variable you can set to control the number of decimal places. Oh well, no big deal. Things are working now, thanks guys. Later, Mike -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading