|
I've been interested in the same thing for some time now, but every time the subject comes up on the list here it just degrades into a holy war over which is the better method, rather than any meaningful discussions on the best tools, methods, practices, etc. to use to implement a DDL-based system. I've yet to see anyone come forward and say "Yes, we've used DDL for everything over the last 10 years and here's what we've learned....". Or "We tried it, and ran into these problems...." Some real-life experiences, not just opinions from those of us who haven't really tried it a real production environment. Most of us have such heavy investments in DDS (20-25 years of existing code) that it's hard to justify and/or sell changing how we develop/maintain files without some real compelling reasons for doing so. The reason that would seem to be the most compelling to me would be tools that would make life easier, like a CODE/400 for database. Is there such a thing? I would like to know (and I think this is more along the lines of what you are asking...): Does anyone actually use SQL's DDL on a day-to-day basis? What has been your experience? Did you convert over existing databases or do you only use it for new development? Do you maintain source members for each file like we do with DDS, or whole Table/View/Index sets in one source member, or even whole libraries (Collections)? Or, do you use some tool that organizes things for you? What are the do's and don'ts you've learned the hard way? Do you utilize a DBA to maintain everything or do programmers maintain their own files and just adhere to some in-house standards? How well has it been accepted by your staff programmers? I think (but have had no experience here) that there are a lot of PC-based SQL tools that might make our lives easier if we were used to using SQL for defining and maintaining our databases, but I'm not sure how easy they are to integrate with the 400. Has anything like this been ported to the 400 for native use? Does anyone use something like Access to model/define their databases and then port that to the 400? How about data dictionaries? Is there anything useful or considered a standard in that area, that could then be used to build our files from? > -----Original Message----- > From: Chevalier, Rick [SMTP:Rick.Chevalier@americredit.com] > Sent: Tuesday, January 07, 2003 3:59 PM > To: 'midrange-l@midrange.com' > Subject: Changing database to SQL from DDS > > My company is looking at changing our database to be SQL based instead of > DDS. I would like to know of anyone's experience converting files to SQL > from DDS along with pros and cons of having your database developed in > SQL. > We are primarily a RPG shop with some web development. There is also some > data transfer between Oracle databases and our iSeries. > > The posts I found in the archives were several years old and seemed to get > bogged down in finer points of how to implement. I'm looking for a broad > view of the issue right now. > > TIA, > > Rick Chevalier > Sr. Programmer Analyst > > (817) 525-7178 > rick.chevalier@americredit.com > << File: ATT103476.txt >> ************************************************************************************************************************************************************************************************************ This message originates from Lincare Holdings Inc. It contains information which may be confidential or privileged and is intended only for the individual or entity named above. It is prohibited for anyone else to disclose, copy, distribute or use the contents of this message. All personal messages express views solely of the sender, which are not to be attributed to Lincare Holdings Inc., and may not be copied or distributed without this disclaimer. If you received this message in error, please notify us immediately at MailAdmin@lincare.com or (800) 284-2006. ************************************************************************************************************************************************************************************************************
As an Amazon Associate we earn from qualifying purchases.
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.