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.
amazon.com ads help fund midrange.com operations