Re: @%#$@!% RDS 6.01

Please verify the version you are using. 6.01.UC1 was withdrawn almost immediately and the main release version was 6.01.UD1. The actual cause of the change was wholly unrelated to this (it had to do with what was provided to source code customers), but I need to know hardware and software if you really have 6.01.UC1 -- and where you got it from. Running 6.01.UD1 FGLPC on Sparc 10 running Solaris 2.4 and the minimal code below, I get no compilation errors. When I run it against 6.00.UE1 OnLine, I do get the run-time error. Does this happen for you with this code? MAIN DATABASE stores SELECT * FROM customer INTO TEMP __table_x END MAIN A quick perusal of the object code with a hex dump shows what the problem is: 0x0000: 01 00 0A 02 00 08 6B 6B 2E 34 67 6C 00 00 30 30 ......kk.4gl..00 0x0010: C0 E5 00 06 06 00 05 6D 61 69 6E 00 00 00 00 00 .......main..... 0x0020: 00 00 07 00 22 53 00 02 84 00 00 00 00 91 00 04 ...."S.......... 0x0030: 00 00 53 00 04 7C 00 10 00 00 00 00 91 00 04 00 ..S..|.......... 0x0040: 00 53 00 06 79 00 00 08 00 3A 64 61 74 61 62 61 .S..y....:databa 0x0050: 73 65 20 73 74 6F 72 65 73 00 73 65 6C 65 63 74 se stores.select 0x0060: 20 2A 20 66 72 6F 6D 20 63 75 73 74 6F 6D 65 72 * from customer 0x0070: 20 69 6E 74 6F 20 74 65 6D 70 5F 5F 74 61 62 6C into temp__tabl 0x0080: 65 5F 78 00 1B 00 04 00 01 00 01 FF FF 00 02 00 e_x............. 0x0090: 02 00 00 00 04 00 04 00 0D 00 06 00 06 00 1C 05 ................ 0x00A0: 00 49 73 74 61 74 75 73 00 69 6E 74 5F 66 6C 61 .Istatus.int_fla 0x00B0: 67 00 71 75 69 74 5F 66 6C 61 67 00 73 71 6C 63 g.quit_flag.sqlc 0x00C0: 61 00 73 71 6C 63 6F 64 65 00 73 71 6C 65 72 72 a.sqlcode.sqlerr 0x00D0: 6D 00 73 71 6C 65 72 72 70 00 73 71 6C 65 72 72 m.sqlerrp.sqlerr 0x00E0: 64 00 73 71 6C 61 77 61 72 6E 00 03 00 0A 00 00 d.sqlawarn...... As you can see, the compiler has managed to omit a space between the keyword temp and the __table_x. There doesn't seem to be much doubt that it is a bug. As for a workaround, I'd suggest starting all table names with a letter. This should not be as hard to do as all that since you have the double-underscore at the start of the table names. The bug is triggered by a single leading underscore. The bug is known to be present in versions 6.00, 6.01 and 6.02. It is known to be absent from versions 4.00, 4.10, 4.11, 4.12, 4.13. I presume it is absent from 4.14. It is in PTS a bug number B41619. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> PS: About your PS -- what else would you expect? >From: rswa@perth.DIALix.oz.au (Radio Spares) >Date: 15 Aug 1995 15:29:28 +0800 >X-Informix-List-Id: <news.16240> > >Aaarrrgggghhh!!!!! > >I have come across an inconsistency in the new RDS (6.01.UC1). A longtime >ago we decided on a standard for naming temporary tables so that we would >never have a problem of someone creating a real table of the same name >and causing problems for our programs. We decided on using __ in front of >the table name. This worked fine in 4.1 > >Now I find when I am testing my programs after recompiling for the new >Informix that I get a -201 error on the following statement: > >SELECT * FROM table_x INTO TEMP __table_x> >I do it this way as I want to make sure that the temp table mirrors the real >table. I can still select from __table_x, delete from __table_x and load into >__table_x but just that initial statement gives an error. > >We have used this quite extensivly. Before I have to go and bite any bullets >I would like to know if: > >a) this is fixed in a newer version (pleasee!!!) >b) there is a magical command line arguement that gets around it >c) there are any good vacancies for 4gl analyst/programmers around > >TIA > >Jason. > >PS: Did you know that when you execute a database statement (ie database >stores)it not only closes all open cursors but frees them as well and you >need to redeclare the cursors before you can use them!