Rich Duzenbury wrote:

So why not get rid of this 'embedded' idea? So far as I know, it's the only architecture that tries to compile the SQL statements in to the program.

I'm sure python can access an SQL database without having to use an SQL preprocessor. Java doesn't use this preprocessor idea does it? I use perl quite a bit on intel platforms, and it's no trouble to get access:

my $dbh = connect();

# Get last name, first name from the table
my $sth = $dbh->prepare( "SELECT ulnam, ufnam FROM person") ;

$sth->execute;

while ($row = $sth->fetchrow_hashref) {
    # do stuff with each row
    print $row->{ulnam}, "\n";
    print $row->{ufnam}, "\n";
}

Frankly, I've been turned off from even trying to write SQL code on the iSeries because of all of this problematic stuff I keep hearing about the SQL preprocessor. And, few of my clients have the extra SQL licensed program.

I would really like to have SQL access from RPG that's as much of a no-brainer as the perl code above.


I think the main issue is performance. I believe the process of precompiling the SQL results in a more efficient means of performing the SQL queries, which is often an important consideration for programmers who choose static compiled languages, like C, RPG, and COBOL.


But yeah, I agree - for flexibility, you can't beat an interpreted language, like Python or Perl. I like how you can easily construct a query dynamically in Python, and get the results back in a list along with another list that describes the columns returned. Of course the cost of that flexibility is run-time performance. But personally I think the dynamic nature of SQL makes it a natural match for dynamic languages like Perl or Python.

Sure, if you want, you can do SQL programming in RPG without having to use the preprocessor, using the SQL CLI. But I'm not sure if anyone has given up on the SQL prep in favor of using the CLI.

Cheers! Hans



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.