I find it helpful to develop SQL to be embedded using System i Nav
Run SQL Scripts. My habit is to create and save a .sql file
named for the program or project. I keep these files for
use later for debugging or enhancements.
For complex SQL Statements I'd suggest to create SQL Views that can be
executed and tested in every SQL environment (and even with Query/400).
Because an SQL View has no key, you can have thousands of views on your
system without any performance decrease.
(Contrary to SQL indexes which must be updated as soon as any row in the
base table will be changed).
In this way my (embedded) SQL Source code is quite easy, 'SELECT Col1, Col2,
... ColN from MyView' where sometimes some WHERE conditions and/or Order By
clauses are added.
If something changes I only have to change my view and none of programs,
queries, downloads that use this view must be changed.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im
Auftrag von Gary Thompson
Gesendet: Thursday, 23. June 2011 15:21
An: RPG programming on the IBM i / System i
Betreff: Re: Fw: Embedded SQL error
Richard wrote:
Is there an easier or more intuitive way of debugging embedded SQL?
I find it helpful to develop SQL to be embedded using System i Nav
Run SQL Scripts. My habit is to create and save a .sql file
named for the program or project. I keep these files for
use later for debugging or enhancements.
Having SQL commands separate from program code simplifies coding
and allows me to focus.
Using FIND, I see six CAST and only five AS in your statement,
so I would, as Michael Schutte suggested, start with
that mis-match.
midrange.com
