kenm@natinst.com (Ken McKinney) (05/26/90)
We've just upgraded to a new version of Informix SQL (the old one was
crashing our new 3B2-1000). All of a sudden I'm encountering really strange
problems when running ACE reports. The reports compile correctly, then error
out with message # -217, column(column_name) is not found in any table in the
query, or something like that. But the column is in one of the tables which
my select clause references.
Here's the wierd part which convinces me I've got a real bug.
by altering the order of the columns in my select statement I can change the
column which is reported as not found. For example
select compnme,shpzip,customer_id,partdesc,quantity......
wrongly says that column customer_id is not in any of the (3) referenced tables.
select customer_id,compnme,shpzip,partdesc,quantity.......
says that shpzip is not in any of the tables.
Nothing is changed save the ordering of the columns in the select statement.
Has anyone encountered a similar problem? Does Informix acknowledge this as
a bug?
Any help would be greatly appreciated.
Ken McKinney
(kenm@natinst.com)
National Instruments
Austin,Texasaland@infmx.UUCP (Colonel Panic) (05/27/90)
In article <10578@natinst.natinst.com> kenm@natinst.com (Ken McKinney) writes: > We've just upgraded to a new version of Informix SQL (the old one was >crashing our new 3B2-1000). All of a sudden I'm encountering really strange Immediate warning sign. When you say that this is a "new version" and "the old one was crashing <the machine>", something is seriously wrong. First of all, what version and port were you running before? If it's *that* old, it wasn't ported to the 1000 series anyway, and running other ports (even if the hardware mfr tells you they are "compatible") could be a danger sign. Also, depending on *how* old your prior version was, you may need to run a conversion utility -- for example, if you were converting from 1.10 directly to 2.X0.XX, you would have to run dbconvert before attempting to use your database. Another red flag is the concept of "crashing the machine" in general. Any regular user program should never "crash the machine" unless your kernel is already unhealthy... >problems when running ACE reports. The reports compile correctly, then error >out with message # -217, column(column_name) is not found in any table in the >query, or something like that. But the column is in one of the tables which >my select clause references. It would also help if you mention which engine you are using (SE or Turbo/OnLine)... >Here's the wierd part which convinces me I've got a real bug. > >by altering the order of the columns in my select statement I can change the >column which is reported as not found. For example > > select compnme,shpzip,customer_id,partdesc,quantity...... > >wrongly says that column customer_id is not in any of the (3) referenced tables. > select customer_id,compnme,shpzip,partdesc,quantity....... > >says that shpzip is not in any of the tables. > >Nothing is changed save the ordering of the columns in the select statement. >Has anyone encountered a similar problem? Does Informix acknowledge this as >a bug? Not yet, anyway. The behavior you mention hasn't been reported by *anyone* else and didn't show up in porting QA. There are 5 immediate possibilities that come to mind: 1) running the wrong port. Your platform ID should be in the range 001079 to 001084. 2) updating from 1.X to 2.X+ without running dbupdate. 3) having used the 2.1 release to access the database (forcing automatic conversion to 2.1 format), later tried to use an older release to access the database. 4) having used the 4.0 release to access the database (forcing automatic conversion to 4.0 format), later tried to use an older release to access the database. 5) other forms of catalog corruption. If you are using the SE (Standard Engine), try running bcheck against the catalog tables. (If you prefer, you can instead use CHECK TABLE for any table but "systables"). If the tables aren't too huge, you can also try unloading the table data, dropping and recreating the database, then reloading from scratch -- this will eliminate catalog corruption due to improper update practices as mentioned above. >Any help would be greatly appreciated. > >Ken McKinney -- Alan Denney @ Informix Software, Inc. "We're homeward bound aland@informix.com {pyramid|uunet}!infmx!aland ('tis a damn fine sound!) ----------------------------------------------- with a good ship, taut & free Disclaimer: These opinions are mine alone. We don't give a damn, If I am caught or killed, the secretary when we drink our rum will disavow any knowledge of my actions. with the girls of old Maui."