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



Peter

I think this kind of thing is exactly what OA can help with. We ARE always wrapping fairly complex things in simple interfaces - and how simple can a CHAIN be?

It doesn't mean that new things are not in there, as you describe. Nice!

Vern

On 2/3/2012 3:04 PM, Peter Dow wrote:
Hi Scott,

Just some thoughts about this -- how about a handler for HTTPAI? Pass
the URL as a key and get back the website as a record on a CHAIN?

I haven't done any SOAP or REST stuff, but how about stuffing all that
in a handler?

Maybe your FTP api?

How about your Excel service program? OPEN the spreadsheet, READ
through the rows, CHAIN to a specific row, WRITE a row?

It's great to know a lot of new stuff, but even after I know it, I'm
always trying to find ways to encapsulate it so I don't have to
constantly deal with the details. That's why we write procedures,
service programs, etc. If there's another way to reduce the complexity
of a program so the business logic is clearer, I'm all for it.

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx<mailto:pdow@xxxxxxxxxxxxxxx> /

On 2/2/2012 3:29 PM, Scott Klement wrote:
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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.