×
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.
Hi Vern,
An obvious possibility for me is remote databases. You have put together
great material on using JDBC - your service program could be the core of
a nice handler - just as I've done that with our RPG2SQL product.
I approach this with a similar stance as UI modernization. Shouldn't we
be using SQL to access remote databases instead of native record-level
I/O?! Wouldn't that be better.
Sure, you could say that there are lots of existing programs out there
using native I/O and maybe users want to have them work with SQL Server
or Oracle or something without rewriting the code. Okay, I can see that
-- but, again, that's a quick-fix, not the ultimate goal. The ultimate
goal should be to use SQL.
Dieter Bender has already written an ARD driver for JDBC so you can use
the dynamic embedded SQL operations (EXEC SQL) for accessing other
databases like SQL Server, Oracle, MySQL, etc. Isn't that a better
solution than OA?
At least "normal" native I/O, has a minor performance advantage over
SQL. With an OA driver to a JDBC connection, it'd be the opposite, the
direct SQL would actually be faster than the OA calls (which would use
SQL under the covers, but wouldn't be able to do set-based processing.)
Not to mention that the handler would be really tough to write. As you
mentioned, a CHAIN would be easy. So would a WRITE opcode. But what
about SETLL or READE? What SQL statements would you translate those to?
How about UPDATE? The native I/O UPDATE updates a record that's
already loaded in memory and locked for the program's use. How on earth
would you do that in JDBC?
For stuff like CSV files, I think it makes sense, though. But, there
aren't a lot of areas where I think it fits.
midrange.com
