Re: Truly later thinking...Honey, grab me another beer

Matt,

Regarding using prepared statements and database updates, my inclination would be to call an RPG program from Net.Data, and particularly if the transaction involved database updates, and also if a DRDA connection to a remote database were involved. If you need access to mySQL or a Microsoft database, then I'd look at a JDBC interface. I've read that Net.Data can interface with Java.

Regarding SQL injection, I came up against that in the macro I just wrote, and decided to allow only a maximum of 16 bytes on the last name input to ward off hackers. I used the Net.Data substring function.

If someone tries to inject something malicious into an SQL statement and the database complains, or even if the database complains for any other reason, I liked the optional %message block, where you can send your own message or forward the actual message that's output to the job log to the browser. You don't have to go through gyrations to send the right message to the browser.

Nathan.




----- Original Message ----
From: "Haas, Matt (CL Tech Sv)" <matt.haas@xxxxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Thursday, August 14, 2008 11:39:18 AM
Subject: Re: [WEB400] Truly later thinking...Honey, grab me another beer

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Thursday, August 14, 2008 12:41 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Truly later thinking...Honey, grab me another beer

From: "Haas, Matt
At this point, I don't know why anyone would want to start new
development in Net.Data.

Let me admit that the lack of traction is a valid concern. But that could change quickly if IBM chose to commercialize it, or help establish an open-source community around it. Like any product, it needs someone promoting and supporting it.

If you just consider Net.Data architecture and features, there's a lot going for it. It runs in the native virtual machine and offers an exceptional interface with native language environments. Contrast that with products that offer a migration path off the platform. A good word-smith may characterize them as IBM i modernization tools, but they're actually migration tools - a good way to kill a platform.

<snip>

I can't say I disagree with any of the points you've made but there is one thing that is really problematic with Net.Data and that is the built in database access. There are two huge issues with it that have caused me no end of grief.

The first is that there is no way to do prepared statements. This makes it extremely difficult to write a macro that updates data that isn't open to SQL injection attacks. Sure, you can write programs to do I/O but then that pretty much kills the simplicity.

The second problem is with accessing multiple databases. I know that it does it (any pretty easily at that) but the problem is it has absolutely no error recovery when the connection goes south. For example, if you write a RPG IV program and put it in activation group *CALLER (which is what Net.Data runs in and what IBM recommends for CGI programs) and that program establishes a connection to a remote system but doesn't explicitly reset the connection to the local machine when it ends, Net.Data will not be able to do any I/O with the local machine until something else either resets the connection or you restart the HTTP server. IBM is blaming this on limitations of SQL CLI but I personally find it hard to believe that particular interface can't handle this. This bug was reported to IBM over 10 years ago and they flat out said it will not be fixed.

I also find the syntax a little messy (especially if you need to do something complicated) but it is straightforward. Has anyone else here used SiteBoss/400? It was a decent (but slightly buggy and very slow) editor that helped a lot. I don't know of anything that replaced it (honestly, I haven't looked either -- the above mentioned data issues convinced me to use something else) which makes developing anything other than trivial scripts difficult.

Matt