We have gone through a slow process of doing all new development using SQL DDL instead of DDS because of tools and the ability to map it so an NT DB2 database for testing, etc. Especially now that stored procedures and triggers can be SQL based (5.1 with the built in C compiler), it makes the code more "portable". But you already have UDB on the 400 - opps iSeries. Now you can go back to management (after the holidays) and tell them you spent the whole time off working on implementing it, and did it without spending any money on your own time! jb John Bussert Swift Technologies, Inc. www.swiftorder.com 847-289-8339 847-289-8939 (fax) email@example.com -----Original Message----- From: R. Bruce Hoffman, Jr. [mailto:firstname.lastname@example.org] Sent: Thursday, December 20, 2001 9:01 AM To: email@example.com Subject: Re: UDB question ----- Original Message ----- From: "Dan Rasch" <firstname.lastname@example.org> To: <email@example.com> Sent: Wednesday, December 19, 2001 1:37 PM Subject: UDB question > I was just told there is a directive from management to look into > UDB for the 400's DB2. Apparently the claim is that if we replace > our DDS with SQL definitions, we can change file defs (like adding > fields to the end of the record) without the level checks. Level checks are not caused by the definition (DDL of SQL) but the access and manipulation of data (DAL of SQL) through programs that refer directly to the file and it's external definition. SQL _access_ (select, delete, insert, update) if done _without_ the * (ie. select * from a into bstruct) will ignore level differences on the record because it looks at the field level, not the record level for its data. As for UDB, on the 400 it's just a name. If you have an AS400 or iSeries, then you have "DB2 UDB for OS/400". There are three flavors (and producers) of DB2 UDB. One runs on the 400, one runs on 390 architecture and (IMO the true UDB) the last runs on just about everything else with a common code base and comes from Toronto. The 400's version of DB2, in many cases, lags behind the facilities of the "all platform" version of UDB and the 390's version. The glaring exception was EVIs which made it to the 400 first. But the 400 still does not support grouping sets, rollup and cube operations, although it finally has declaritive triggers, and more than 6 allowed. Also IMO, switching the definition to SQL allows you to use tools for database design, modelling, creation, maintenance and documentation. All well worth the effort. =========================================================== R. Bruce Hoffman, Jr. -- IBM Certified Specialist - iSeries Administrator -- IBM Certified Specialist - RPG IV Developer "I want to be different, just like everybody else!" - Ceili Rain _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-Lfirstname.lastname@example.org Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.