Re: Using directives within Informix 4GL

You could try wrapping the select in an SQL...END SQL block, but it's very possible that 4gl will still just see a comment If you prepare/execute it, then you'll need to use {+ ... } since the whole statement will effectively be on one line hth >>> Madison Pruet <mpruet@home.com> 01/29 5:34 pm >>> Did you prepare the query? Paulo Amorim wrote: > Does anybody knows how to use directives within an Informix 4GL program > ?? > > What I want to do is a query like this: > > select --+ordered > * from a,b,c > where a.a = b.b > and b.b = c.c > > The directive is not followed when the query runs. I can see that when > I use onstat -g sql or when I use sqexplain. > > Is there any other special syntax to be used ??? > > Thanks > -- > Paulo Roberto Marelli de Amorim > TS&0 Consulting > Brasil > > Sent via Deja.com > http://www.deja.com/

Richard Harnden wrote: > You could try wrapping the select in an SQL...END SQL block, Hooray; someone got it right! > but it's very possible that 4gl will still just see a comment No, if you have version 7.3 I4GL, then you can use an SQL...END SQL block, and the directives will be handled correctly. If you don't have 7.3 I4GL, then prepare and declare is the only solution, because, as people pointed out, -- introduces a comment, and the + is simply ignored as the first character of the comment. Hints arrived on the scene long after -- comments. > If you prepare/execute it, then you'll need to use {+ ... } since the whole > statement will effectively be on one line Or you can embed a newline, ASCII(10) at the end of the hint so that the SQL parser will see a newline marking the end of the hint. > >>> Madison Pruet <mpruet@home.com> 01/29 5:34 pm >>> > Did you prepare the query? > > Paulo Amorim wrote: > > Does anybody know how to use directives within an Informix 4GL program? > > > > What I want to do is a query like this: > > > > select --+ordered > > * from a,b,c > > where a.a = b.b > > and b.b = c.c > > > > The directive is not followed when the query runs. I can see that when > > I use onstat -g sql or when I use sqexplain. > > > > Is there any other special syntax to be used ??? -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"

Jonathan Leffler wrote in message <3A7708D1.A3CFFB4@informix.com>... >Richard Harnden wrote: >> You could try wrapping the select in an SQL...END SQL block, > >Hooray; someone got it right! > You are obviously a fan of SQL ... END SQL but I gotta admit - my mind is boggled at the move away from inline SQL towards this old-fashioned-looking concept in 4GL. One of the beauties (IMHO) of 4GL is the integrated SLQ syntax and I'm stuffed if I know why 4GL can't be modernised in the same vein instead of moving towards embedded sql-style language constructs. Why? WHY? What's the justification? Is it because the home-made additions to SQL with the universal server options is totally beyond hope when it comes to parsing the 4GL? That's the only excuse I can think of... Lessons please!

Andrew Hamm wrote: > Jonathan Leffler wrote: > >Richard Harnden wrote: > >> You could try wrapping the select in an SQL...END SQL block, > > > >Hooray; someone got it right! > > You are obviously a fan of SQL ... END SQL but I gotta admit - my mind is > boggled at the move away from inline SQL towards this old-fashioned-looking > concept in 4GL. I'm more of the culprit than a fan -- it was my recommendation. A pragmatic one. See below. > One of the beauties (IMHO) of 4GL is the integrated SLQ syntax and I'm > stuffed if I know why 4GL can't be modernised in the same vein instead of > moving towards embedded sql-style language constructs. Why? WHY? Resource limitations. > What's the justification? > Is it because the home-made additions to SQL with the universal server > options is totally beyond hope when it comes to parsing the 4GL? That's the > only excuse I can think of... > > Lessons please! Well there are problems in that area: Try explaining which of these braces belong to comments and which are syntactically significant, and why: TABLE{}({}MULTISET{{}ROW{}({}1{},{}'Paul'{},{}'Paul'{}){}}}) Now go cry into your home-made lexical analyzer for Informix's dialect of SQL. Now work out where the spaces are allowed. And the new lines. And the -- comments. And the lower case letters in the keywords, or the mixed case keywords. And go weeping some more. [Yuck! - and check out the test code in iustoken.c in SQLCMD, and let me know if there are any bugs left in it!] More significantly, a given version of I4GL is released at time X; a new version of a database is released at time Y, Y > X. I4GL cannot predict the syntax that will be part of the new version of the database (for Y is much later, many years later, than X). The PREPARE statement is a workaround. It might be possible to extend the SQL grammar in I4GL to handle these new statements, but...the grammars on which I4GL is built are exceptionally contorted, and there are a number of them (for the p-code compiler, for the c-code compiler, and the 4ec->ec compiler each has its own grammar, and these are built out of spare parts, using different technology from the current CSDK and server compilers). The advantage of the SQL...END SQL block is that it gives you access to any new feature in the server with the minimum of fuss. The primary disadvantage of the SQL...END SQL block is that it defers to runtime error checking that might otherwise be done at compile time. However, if you have an I4GL compiler that recognizes all the latest whizzy ISO SQL outer joins and the like, and which correctly recognized that your code is syntactically correct, it is no help if in fact the server you are using at runtime does not recognize it - you still get the runtime error. Pragmatically: the SQL block was relatively easy to add and handle. Doing the job properly would have cost more than Informix would have been prepared to invest in revising the I4GL compilers. It allows you to deal with most statements, whether or not CSDK knew about them at the time I4GL was released -- and does so without requiring an explicit PREPARE. It works -- it is better than nothing. -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"

Jonathan Leffler wrote in message <3A78B125.1D8418B1@informix.com>... > >I'm more of the culprit than a fan -- it was my recommendation. A >pragmatic one. >See below. I dd, with relish. <SNIPS> >Pragmatically: the SQL block was relatively easy to add and handle. >Doing the job properly would have cost more than Informix would have >been prepared to invest in revising the I4GL compilers. It allows you >to deal with most statements, whether or not CSDK knew about them at the >time I4GL was released -- and does so without requiring an explicit >PREPARE. It works -- it is better than nothing. > Well, I'm convinced. Good answer, and refreshing honesty from within.