• Subject: Re: RPG SQL precompiiler
  • From: "Nelson C. Smith" <ncsmith@xxxxxxxx>
  • Date: Thu, 15 Jul 1999 00:06:30 -0400

Hey, this is a great opportunity!  Thanks John.

My biggest headaches have been caused by the precompiler ignoring the
compiler directives Define/Undefine.  It brings in the entire copy member
which probably contains duplicate fields, assorted line types, etc, which is
why I was using the Define/Undefine directives in the first place.  I would
also like to be able to bring in the same boiler plate code at multiple
insertion points.

My second biggest headache is how it ignores the existence of subprocedures,
I guess thinking they are just subroutines or something.  If you have the
same field names defined locally in them, it thinks they are doubly defined.
This is a real problem in a service program where you may have many very
similiar procedures.  If you try to use the same cursor name, for example,
in each procedure, it thinks they are doubly defined.

The combination of these two makes it almost impossible to come up with
boiler-plate SQL code used in multiple procedures in the same service
program.

And as you mentioned, even for "real" subroutines, the order listed is
critical.  I've also had errors where it thinks the D-specs in the
procedures are "out of sequence" because other procedures ahead of it have
C-specs.

Also, a general question I have for the developers is:

If I can Insert from a host variable and select into a host variable, why I
can't I update from a host variable?  I know the answer is probably going to
be because normal SQL doesn't support it, but what is normal about our
precompiler?  As long as it is embedded into RPG anyway, it certainly isn't
going to be used anywhere else, so why can't we have some additional
functionality added to it.

-----Original Message-----
From: John P Carr <jpcarr@tredegar.com>
To: RPG400-L <RPG400-L@midrange.com>
Date: Tuesday, July 13, 1999 11:05 PM
Subject: RPG SQL precompiiler


>Hey Guys,
>
>I forwarded our comments about the SQL precompiler to a friend of mine in
>Rochester
>who works on SQL,   This is his response(Below).   Do we/Can we come up
with
>a list of examples I
>can forward to him about our problems???    Like the single pass compile
>problem(Prepare has to be
>physically before the Fetch in the calc's , etc)?   Send them to me and I
>will forward them to the SQL team.
>I will report on our progress
>
>Respectfully
>John Carr
>
>>> Rochester owns the SQL precompilers.  Talking to the developers they're
>not
>>>aware of some of these ordering deficiencies (outside of compiler
>directives).
>>> Are there some examples of this wierd ordering behavior that people
could
>send
>>> in and I could pass along to the developers?  The other option is to
just
>tell
>>> people to report it as a bug and I'll let the developers know.
>
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>* This is the RPG/400 Discussion Mailing List!  To submit a new         *
>* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
>* from this list send email to MAJORDOMO@midrange.com and specify       *
>* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
>* be directed to the list owner / operator: david@midrange.com          *
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].