Re: SQL pre-processor (was RPG IV release levels and complexity)

[Rich Duzenbury <rduz-midrange@xxxxxxxxxxxxxxxxxxx>]

> 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.

How much more efficient?


> 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.

Any benchmarks on the static vs dynamic?  Doesn't the query manager cache 
any of this stuff?  Let's say the system runs the same OPNQRYF 5,000 times 
a day in 1,000 different jobs.  Isn't the access path available to all 
1,000 different jobs, or does it get built 5,000 times?   Same question for 
SQL access.

Where does java fit in to this?  Does it use a precompiler for the SQL 
statements or does it react like an interpreted language?


> 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.

Is the CLI available as part of the base OS, or is it only available with 
the extra SQL licensed stuff?

Is the CLI easy to use?

Thanks!

Regards,
Rich