Just so we're clear on this Joe, you think ODBC is bad, eh ? ;-) (The eh,
was my canadian/Minnesotan impression.)
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.
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.
Your point about security can be mitigated somewhat by wrapping all SQL or
database access into a business layer as I advocate and I believe you do
as well with the messaging architecture that you recommend. You can
definitely reduce the possibility for hacks if you use the message based
approach, but since most other non-iSeries database applications support
data access via direct SQL or business objects that use SQL, I don't think
we can hang our hats on not using SQL.
Here's my thoughts on why:
<A little soapboxing>
I know the message based architecture concept is fast and safe and all
that, but I am regularly running into people who are fighting to keep
their iSeries systems alive in the realm of 30-something CIO's who want to
dump the iSeries because of the green screen. While this is not really a
good business move, we can't continue to always fight the "I want to use
SQL to access the iSeries, how do I do it" complaints with "You need to
write special iSeries code to keep the programmers and hackers safe from
the system". If we do that, then the youngling's will eventually win the
war and the iSeries will continue to get dumped.
If we instead talk about the concepts of using safe business objects to
wrap database access or messaging access so that the code is re-usable
across applications and SQL is not embedded into pages directly, then
maybe the young Linux/Windows-Generation will learn the value of writing a
"business layer" instead of throwing a bunch of spaghetti SQL into some
quick web pages.
We sold a VB tool called DDA/400 back in the 90's in the early days of
iSeries SQL and ODBC. The main reason for this tool was record-level
database access for speed. With JT400 and other tools today, the need for
a tool like DDA/400 has been eliminated but I can't count the number of
calls we took where the PC developers would say "That record level thing
sounds good, but we need to use SQL for flexibility". In the late 90's we
saw the handwriting on the wall in regards to SQL being used more and
more, so I believe we must teach "safe SQL", not abstinance :-)
</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. Then the
logic can be used from another RPG program, an PC web page application or
a business object written in Java or VB or C# or whatever......
At lease we're giving people food for discussion :-)
Regards,
Richard Schoen
RJS Software Systems Inc.
"Providing Your....iNFORMATION NOW!"
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 898-3038
Fax: (952) 898-1781
Toll Free: (888) RJSSOFT
------------------------------
message: 4
date: Sat, 25 Nov 2006 11:19:51 -0600
from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
subject: RE: Updating files from the web
I don't want to put words into Eduard's mouth, but I think the issue was
more about ODBC rather than SQL.
ODBC is bad.
