Re: RLA & SQL was (Re: SQL database object names longer than 10 charactersand mixedcase?)

that would be my recommendation: if you are using diffrent technologies,

one

of them should be encapsualted, so that nobody has to deal with both.

But in

this case it would have drawbacks and I wouldn't do so. You would loose

the

ability for positioned updates, which are much faster than searched

updates,

because the need no repositioning and if you need read stability with
following updates, the update modules are useless, they won't get the

record

locks, they need. In my opinion transaction handling gets rather
complicated.

Almost everything here is incorrect. You do not loose positioned updates
when using RLA, everything is positioned. You loose set based operations.
In fact positioned operations take a bit more work with SQL because you
have to define a cursor to get them. And transaction handling is no
different between SQL and RLA. You tell the system you are going to use
commitment control, and you put in commit or rollback in the appropriate
places. You can mix and match SQL and RLA, it still works. Actually SQL
makes things a bit more difficult because each and every SQL statement
opens a new ODP (except cursors), while RLA only opens one per F spec.
Using modules complicates things if you use RLA, because you have extra
access paths, but no more complex than SQL with it's separate ODPs.

. . .

agreed, its possible (nearly nothing is impossible, its always a

question of

effort), but I never saw commit used with RLA, ist even rarely used with

SQL, thow its rather easy to use with SQL; thats one point, where the

RPG

community is far away from state of the art and it has something to do

with

RLA!?

No, it has nothing to do with RLA, it has everything to do with the high
cost of disk space when most RLA applications were first written, and
momentum. Back in the early days, it was far too expensive to journal
everything, so commitment control was not common. Even in applications
that used SQL back then. Had nothing to do with capability.

You said "Using two concurrent technologies to do the same, (DDS and
DDL, or SQL and RLA) complicates application developments and the
readability of code is worse, then concentrating on one of the
technologies, so there is a decision to make between SQL and the

native

interfaces". I'm sorry, I really don't see how the readability of code
is worse.

Same thing with mixing up RPG and Java, a programmer who has to do
maintenance in a programm using SQL and RLA has to have knowledge with

both

technologies. Encapsulation (as you mentioned before) would help, but

the

problem is not gone, if you are searching for bugs (caused by lock
contention for example).

If you know RPG, then you know RLA, otherwise you will likely have a hard
time getting an RPG job. That is just base knowledge. It is using SQL
that will trip up RPG programmers if anything. So if we subscribe to your
readability argument, and I don't, we shouldn't use SQL at all. If SQL is
known, then there is no issue here. Java is different. It is a totally
different animal, and most RPG programmers don't know it, or any other OO
language.

You said "RLA transfers binary huddle between the database and the
application with higher risc of data corruption." How?

Data Structures are untyped storage description (I call this binary

huddle,

since I've written ArdGate) . If a datastructure doesn't match the

record

format, you would transfer every nonsens to or from the database, using

SQL

the compiler will do more checking for you and at runtime the database

will

do more checking at column level, even if you would use Datastructures

in

your programm. (BTW: IBM claims that DDL Tables would be faster than DDS

Tables and they claim a single database operation would be faster with

SQL

than with RLA - in my opinion and experience both are marketing, SQL is

a

little bit slower in real world and needs a little bit more ressources -

you

don't get anything for nothing!!!!!!!)

If you are using level checks properly, then this is a non-issue.

Mark.