RE: Updating files from the web

From: richard@xxxxxxxxxxx

Actually we work with the iSeries Access ODBC, .Net Provider and JDBC
quite regularly and we typically achieve sub-second response times, so in
my opinion based in experience, performance isn't much of an issue in
today's environment.

I never really talked about performance except in the context of
applications spanning companies, requiring different environments, and so
on.  There we have the fundamentally flawed concept of connection pools,
simply because the cost of creating a connection is so high.  But the
problem is that the connections can't have any persistence (like, oh, say, a
library list), so you have to have persistent connections, which removes the
benefits of connection pooling in the first place, or you have to hardcode
your environment settings on every SQL call, which nobody does in modern
programming.

In terms of managing library lists, if we put SQL into a business object,
we have properties that get set in the business object to control library
lists for the data. We also qualify our SQL with the library name where
the tables reside. Seems to work quite well and give us complete control
over which library we're accessing.

Oops.  Okay, SOME people hardcode library names <grin>.  Welcome to the
1980s!

Seriously, though, that's one of the two big problems with thick-client
programming: you end up using outmoded concepts like hardcoded libraries
(and user IDs and passwords) in order to get around the basic shortcomings
of the operating system.

The second, of course, is the age-old problem of distribution of program
changes.  But that's a completely different subject.

<A little soapboxing>

(...)
For the seasoned iSeries developers, a nice happy medium is the concept of
using stored procedures to access data from a business layer.  The concept
of calling an RPG stored procedure and returning a result set lets all the
SQL access live in the iSeries database and within RPG programs.
(...)

</A little soapboxing>

Exactly.  Use stored procedures to call RPG and get rid of the ODBC direct
access to the tables, especially in update mode. And not only that, your
business logic doesn't have to be in SQL, either!  It can use SQL when
appropriate, and native I/O when the logic is too complex or data-driven for
standard SQL.

But in neither case should you allow unfettered ODBC access to your
database, and especially not in update mode.

ODBC is NOT SQL.

ODBC is bad.

Joe