Re: Changing database to SQL from DDS

----- Original Message -----
From: "Smith, Nelson" <NSmith@lincare.com>
To: "'Midrange Systems Technical Discussion'" <midrange-l@midrange.com>
Sent: Wednesday, January 08, 2003 9:19 AM
Subject: RE: Changing database to SQL from DDS


> 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 would agree with that. To that end, I (at least I hope I) am not telling
people which is "better", merely pointing out the reality of the situation.
Railing about DDS being better won't stop the change.

> 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?

Two points, two answers. I have used it in production, both from ground zero
and from retrofit perspectives. The scars could fill a book, but I, at this
point in my career am not writing about it.
Ont the CODE for database, several have been discussed just in this
thread... ErWin, ERStudio and others.

> 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?

Yup.

> What has been your experience?

Mixed but good overall.

>  Did you convert over existing databases or
> do you only use it for new development?

Yup.

> 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?

Both and Yup. I use both ErWin and Embarcadero's ERStudio.

> What are the do's and don'ts you've learned the
> hard way?

Learn what indexes are for. Separate programs from physical dependancies and
from physical dependance on logicals. This is a "learned" 38/400 trait. We
build logicals and then access them. In SQL you build and access physicals,
tune with indexes. Secure and construct with views.

> 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?

Consultant. DNA. (Does not apply)

> 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?

The tools can connect to the 400 and execute. They can generally connect to
ANY ODBC enabled database. Each of the tools support many databases but
provide a common interface to those disparate platforms.


===========================================================
R. Bruce Hoffman, Jr.
 -- IBM Certified Specialist - iSeries Administrator
 -- IBM Certified Specialist - RPG IV Developer

"When I die, I want to die like my grandmother who died peacefully
  in her sleep. Not screaming like all the passengers in her car."

    - Author Unknown