× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 9/6/2011 4:04 PM, Morgan, Paul wrote:
Why isn't it suited? RPG throws errors on file level checks when the
table format changes. It can't do the same for a missing or changed
column? Don't you get warning or hard errors with embedded SQL?

RPG already has three native ways of handling file i/o (not counting SQL) It has Input/Output specs, externally defined files, and data structure I/O.

All of them are based on physical positions within a record. RPG requests an entire record from the database, and then splits that record into fields using from/to positions.

With externally defined files, the input/output specs are automatically generated at compile time -- but they still exist.

Data structure I/O bypasses input/output specs, but it reads a raw record buffer (whole record at once) into the data structure. It does not go through the record field-by-field.

What you are suggesting would require RPG to go through the record one field at a time, determine the data type of the fields, and convert from the file's field type/size to the program's file type/size.

Would that work? Sure. But it means RPG has to read the database by the field rather than by the record. To implement it would almost certainly require a fourth method of handling files with native i/o. Currently new RPG programmers need to learn program-described I/O specs, traditional externally defined files, and data structure I/O. You are asking for a fourth method that they'd have to learn, that's field-based rather than record-based. I think that's where the "frankenstein" comment comes from -- over the years, it keeps having more functionality added on, so programmers need to learn lots of ways of doing everything...

It certainly can be done, but is it worth it? Is it really that hard to recompile a program? Or, if you truly don't want to, why not use embedded SQL that already does what you want?



Catching type errors as soon as possible is the point. At compile
time instead of run time is better if you can do it. That can be
done with a static typed code variable linked to a static database
column type.

I'm not sure I follow how something like this would catch type errors earlier? Surely you already catch the type errors when you compile?


I'm not really wishing for dynamic typing in RPG. I want dynamic
data conversion between a current database column type (checked at
compile time and rechecked at run time) to a static code variable
type (set at compile time).

(This is the bit my response, at the top of this message, was responding to.)


Isn't embedded SQL a better Frankenstein analogy? Two different
languages stitched together.


Perhaps, but every language out there uses SQL for database access. C, VB, Java, C#, PHP, you name it... and embedded SQL is easier to code and debug (not to mention more efficient) than using an API-based approach like ODBC/CLI or JDBC. So I think embedded SQL compares favorably to the alternative languages.

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.