RE: Dependency tree of packages/procedures and functions
- From: "Leonard, George" <GLeonard@xxxxxxxxxxxxx>
- To: "rjamya" <rjamya@xxxxxxxxx>
- Date: Wed, 12 Jan 2005 14:51:38 +0200
Hi there all
Don't worry they are all talking to each other,
Just being difficult in wanting to do their work to figure out what is
dependant on what, it is not in that they don't know how either.
Just a case of being lazy and thinking the DBA's will figure their work
out for them.
George
=20________________________________________________
George Leonard
Oracle Database Administrator
New Dawn Technologies @ Wesbank
E-mail:gleonard@xxxxxxxxxxxxx
=20
You Have The Obligation to Inform One Honestly of the risk, And As a
Person
You Are Committed to Educate Yourself to the Total Risk In Any Activity!
Once Informed & Totally Aware of the Risk,
Every Fool Has the Right to Kill or Injure Themselves as They See Fit!
=20
-----Original Message-----
From: rjamya [mailto:rjamya@xxxxxxxxx]=20
Sent: 12 January 2005 14:48 PM
To: Leonard, George
Cc: Oracle-L Freelists
Subject: Re: Dependency tree of packages/procedures and functions
I believe what you need is=20
1. have all your developers work in the same schema
2. Let them talk to each other about the changes they are making.
3. developers should know that any change they make can break some
else's stuff, so communication is of paramount importance.
4. pre-release testing is not an option.
Raj
On Wed, 12 Jan 2005 07:06:05 +0200, Leonard, George
<GLeonard@xxxxxxxxxxxxx> wrote:
> Hi all
>=20
> Ok I think everyone misunderstood me,
>=20
> I know the database tracks the dependencies, I can see that easily.
>=20
> Package A dependant on B and B on C.
>=20
> Now we have hundreds of packages, many levels.
>=20
> The developers give gives me a new A, it does not want to compile
> because the spec in C that it also uses has changed. But they did not
> record this dependancy anywhere,
>=20
> The problem is not that much that on the target system it does not
want
> to compile initially, it is the time it takes to figure out why 100
sub
> packages all failed because they forgot about the relation ship. They
> now have to go back to source system extract that package and ship it
> also, considering at the entire time if this might break something
else.
>=20
> The current plan is to write a report that hooks into dba_dependancies
> which they can run when shipping a package to see what the relations
> ships are and consider if they need to ship anything else that is at a
> newer version than on production...
>=20
> Thanks for the guys that got back,
>=20
> PS toad got a nice dependacy viewer for source code based objects.
>=20
> George
> =3D20________________________________________________
> George Leonard
> Oracle Database Administrator
> New Dawn Technologies @ Wesbank
> E-mail:gleonard@xxxxxxxxxxxxx
> =3D20
> You Have The Obligation to Inform One Honestly of the risk, And As a
> Person
> You Are Committed to Educate Yourself to the Total Risk In Any
Activity!
> Once Informed & Totally Aware of the Risk,
> Every Fool Has the Right to Kill or Injure Themselves as They See Fit!
> =3D20
>=20
> Hi all
>=20
> Hope you can help.
>=20
> As with all big projects our developers forgot to listen to us when we
> asked them to keep a dependency tree what calls what.
>=20
> Now we are busy going into pre-prod etc and get asked to move Package
A,
> doing this nicely goes and breaks half the world down the line,
>=20
> I would like to run something against the database (packages,
procedures
> and functions) to generate a dependency list.
>=20
> Any ideas what is out there that can do this (freeware prepared), any
> output acceptable.
>=20
> George
> =3D3D20________________________________________________
> George Leonard
> Oracle Database Administrator
> New Dawn Technologies @ Wesbank
> E-mail:gleonard@xxxxxxxxxxxxx
> =3D3D20
> You Have The Obligation to Inform One Honestly of the risk, And As a
> Person
> You Are Committed to Educate Yourself to the Total Risk In Any
Activity!
> Once Informed & Totally Aware of the Risk,
> Every Fool Has the Right to Kill or Injure Themselves as They See Fit!
> =3D3D20
>=20
>
________________________________________________________________________
> _=3D3D
> __________________________
>=20
> The views expressed in this email are, unless otherwise stated, those
of
> =3D3D
> the author and not those
> of the FirstRand Banking Group an Authorised Financial Service
Provider
> o=3D3D
> r its management.
> The information in this e-mail is confidential and is intended solely
> for=3D3D
> =3D3D20the addressee.
> Access to this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, any disclosure, copying,
> distribut=3D3D
> ion or any action taken or=3D3D20
> omitted in reliance on this, is prohibited and may be unlawful.
> Whilst all reasonable steps are taken to ensure the accuracy and
> integrit=3D3D
> y of information and data=3D3D20
> transmitted electronically and to preserve the confidentiality
thereof,
> n=3D3D
> o liability or=3D3D20
> responsibility whatsoever is accepted if information or data is, for
> what=3D3D
> ever reason, corrupted=3D3D20
> or does not reach its intended destination.
>=20
> =3D3D20 ________________________________
> --
> //www.freelists.org/webpage/oracle-l
>=20
>
________________________________________________________________________
_=3D
> __________________________
>=20
> The views expressed in this email are, unless otherwise stated, those
of =3D
> the author and not those
> of the FirstRand Banking Group an Authorised Financial Service
Provider o=3D
> r its management.
> The information in this e-mail is confidential and is intended solely
for=3D
> =3D20the addressee.
> Access to this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, any disclosure, copying,
distribut=3D
> ion or any action taken or=3D20
> omitted in reliance on this, is prohibited and may be unlawful.
> Whilst all reasonable steps are taken to ensure the accuracy and
integrit=3D
> y of information and data=3D20
> transmitted electronically and to preserve the confidentiality
thereof, n=3D
> o liability or=3D20
> responsibility whatsoever is accepted if information or data is, for
what=3D
> ever reason, corrupted=3D20
> or does not reach its intended destination.
>=20
> =3D20 ________________________________
> --
> //www.freelists.org/webpage/oracle-l
>=20
--=20
------------------------------
select standard_disclaimer from company_requirements where category =3D
'MANDATORY';
_________________________________________________________________________=
__________________________
The views expressed in this email are, unless otherwise stated, those of =
the author and not those
of the FirstRand Banking Group an Authorised Financial Service Provider o=
r its management.
The information in this e-mail is confidential and is intended solely for=
=20the addressee.
Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribut=
ion or any action taken or=20
omitted in reliance on this, is prohibited and may be unlawful.
Whilst all reasonable steps are taken to ensure the accuracy and integrit=
y of information and data=20
transmitted electronically and to preserve the confidentiality thereof, n=
o liability or=20
responsibility whatsoever is accepted if information or data is, for what=
ever reason, corrupted=20
or does not reach its intended destination.
=20 ________________________________
--
//www.freelists.org/webpage/oracle-l
Other related posts:
