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



I don't want to put words into Eduard's mouth, but I think the issue was
more about ODBC rather than SQL.

SQL is fine (although handcrafting INSERT statements is very, very passé; if
you're going to do that sort of thing, at least use updatable cursors).  But
no matter your opinion on SQL, ODBC is bad.  Just plain bad.  The negligible
amount of initial savings you get from being able to quickly whack together
code is almost entirely wiped out by the huge investment in security
infrastructure you need.

ODBC is bad.

For example, you need a valid iSeries user profile and password out in the
wild (especially if your web server is NOT running on the iSeries).  This
immediately opens you up for all manner of attacks, such as FTP.  And even
if you do lock all of your host servers down, you still need to do some
serious programming on your ODBC exit point, because the iSeries doesn't
support either row- or column-level security.

These issues can be gotten around, but it requires a ton of work.  One
method is to have an SQL view for every possible access.  But of course
every time you need access to a different set of columns or a different set
of rows, that means creating a new view.  This is a maintenance nightmare.

ODBC is bad.

And I haven't even addressed the issues of environment setup and performance
that come into play when trying to support multiple library lists in order
to handle multiple companies, something we do every day on the iSeries.

If, on the other hand, your access is entirely through program calls using a
message based technique, then the security is entirely up to you, as is your
environment setup.  You can access the web application via a non-iSeries
user ID and password and let the web application and the back-end business
logic sort out the security implications.

ODBC is bad.

And this is for arguably the most secure platform in the world!  The amount
of programming that is required to try and prevent various SQL injection
attacks and every other manner of bad things in a PC environment is even
worse.  Unfortunately, in the PC world you don't have a lot of options.  But
that's why I don't recommend PCs for business applications.  But that's a
DIFFERENT discussion <smile>.

Joe


From: richard@xxxxxxxxxxx

I have to respectfully choose to disagree with you.

Comments like yours give SQL a bad name :-)

If you write diligent code in Java, .Net, PHP, ASP, RPG or whatever, SQL
is a fine way to insert data into a database from a web application.  You
just want to make sure that you build your SQL statements into a business
layer so that the web pages themselves don't have to contain a lot of SQL
building logic.

This logic holds true whether writing iSeries or PC/Linux web
applications.

Just my two cents :-)



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.