Re: lmatter[1,6] = '011191' does not work, but lmatter[1,6] like '011191%' works perfectly

I guess if this is a bug and I found a way around using "like" operator,=20 probably that will be a an answer from Informix, so I do not see a sense to= =20 call them, if you like you can report this=2E I guess using "like" operator= is=20 slower than substring (maybe not ???), but it works for me fine=2E Thanks for your answer=2E =20 Jonathan Leffler <jleffler@informix=2Ecom> on 10/01/98 01:26:58 PM To: Rafal Furdzik/PaulWeiss cc: informix-list@iiug=2Eorg=20 Subject: Re: lmatter[1,6] =3D '011191' does not work, but lmatter[1,6] like= =20 '011191%' works perfectly On Thu, 1 Oct 1998 rfurdzik@paulweiss=2Ecom wrote: > My select is from a view which is using GROUP BY clause! It works fine > when selecting directly from a table or from a view without GROUP BY=2E > Try this: > > SQL[1]: create table t (lmatter char(10)); > SQL[2]: insert into t values ('011191xxxx'); > SQL[3]: select lmatter[1,6] from t where lmatter[1,6] =3D '011191'; -- WO= RKS=20 FINE! > 011191 > SQL[4]: create view test as select lmatter from t; > SQL[5]: select lmatter[1,6] from test where lmatter[1,6] =3D '011191'; --= WORKS=20 FINE! > 011191 > SQL[3]: drop view test > SQL[4]: create view test as select lmatter from t GROUP BY lmatter; -- HE= RE=20 IS A PROBLEM! > SQL[5]: select lmatter[1,6] from test where lmatter[1,6] =3D '011191'; --= It=20 returns no data! > > Nothing returned !!! Any idea ??? This is a rather different problem -- it seems to be a bug in grouped view handling=2E With the grouped view, I too get a problem on both 7=2E24=2EUC= 1 and 7=2E30=2EUC1 on a Sun Sparc 20 running Solaris 2=2E6=2E Given that you've got the problem on HP and I've got it on Solaris (and on an HP Vectra 486/66 running RedHat 5=2E1 Linux with SE 7=2E24=2EUC5), it is a generic bu= g, at least in the 7=2E2x and later releases=2E You should definitely report this as a bug=2E Go to Informix Tech Support with this test case and this email=2E Get a bug entered if there isn't one already for it=2E If you get it entered, it gets a much higher priority th= an if I get it entered=2E > From: Jonathan Leffler <jleffler@informix=2Ecom> > Date: 09/30/98 06:00:08 PM > To: Rafal Furdzik/PaulWeiss > > On Wed, 30 Sep 1998 rfurdzik@paulweiss=2Ecom wrote: > >[Subject] lmatter[1,6] =3D '011191' does not work, but lmatter[1,6] like > '011191%' works perfectly > > Any idea ???? If I do query "Select lmatter[1,6] =2E=2E=2E" it returns=20= string > > '011191', but Where statement for those criteria does not=2E Why I can=20= not use > > "=3D" ???? > > Which version of which database on which platform? > Please, when asking questions like this, be specific=2E > > What you are seeing smacks of a bug, but we need to know > platform, product and version details before anything > can be deduced=2E > > For instance, on my Sun Sparc 20 running Solaris 2=2E6, > using OnLine 7=2E24=2EUC1, I can run the script: > > SQL[1]: create temp table t (lmatter char(10)); > SQL[2]: insert into t values ('011191xxxx'); > SQL[3]: select lmatter[1,6] from t where lmatter[1,6] =3D '011191'; > 011191 > SQL[4]: > > This looks like the correct result to me=2E It isn't a generic > problem on all platforms and versions, so we need the details > from you before we can do anything useful=2E Yours, Jonathan Leffler (jleffler@informix=2Ecom) #include <witticism=2Eh> Guardian of DBD::Informix v0=2E60 -- http://www=2Eperl=2Ecom/CPAN Informix IDN for D4GL & Linux -- http://www=2Einformix=2Ecom/idn __________________________________________________ This message is intended only for the use of the=20 Addressee and may contain information that is=20 PRIVILEGED and CONFIDENTIAL=2E If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited=2E If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately=2E Thank You=2E __________________________________________________