Package Timestamps

[BJCooperIT]

I was recently told that when I add a function or procedure to an established package that the new item should be added to the end of the specification. For example, if I had:

function F_AAA...
function F_DDD...
function F_HHH...
function F_TTT...

and wanted to add F_RRR, I would have placed it between F_HHH and F_TTT. But I was told it should be added as the last item because this can prevent timestamp issues with dependent items. I thought that when you recompile a package the timestamp changes - period. If this new information is true, can someone explain why?

^{Beware of false knowledge; it is more dangerous than ignorance. ~George Bernard Shaw}
Consultant Developer/Analyst Oracle, Forms, Reports & PL/SQL (Windows)
My website: Emu Products Plus

 

[SantaMufasa]

I'm with you, Barb...I believe that the timestamp is an "all-or-nothing" proposition...that there are not separate timestamps for newer pieces of a package. Whoever gave you the converse impression must give us either documentary proof or (preferrably) "actual" proof (by showing us the differing timestamps in some data dictionary view).

Mufasa
(aka Dave of Sandy, Utah, USA)
[I can provide you with low-cost, remote Database Administration services: see our website and contact me via www.dasages.com]

 

[Beilstwh]

I agree with Dave and Barb! When you add a function to a package, the entire package specification and body must be rebuilt. The created date for an existing package and body will stay the same (assuming CREATE OR REPLACE), but the last_ddl_date will always change and there is no timestamp information maintained on the internal functions within the package.

Bill
Oracle DBA/Developer
New York State, USA

 

[carp]

And I almost agree with Bill - however, if you add a private function/procedure, the package spec does not need to be recompiled. With that small bit of nit-picking done, I would have to put the "separate timestamps" idea into the "Future Features" bin (where it will probably stay for a long time!).

 

[SantaMufasa]

Dave (Carp), it's so nice to see (fairly reliable) evidence that you are still alive and that you still frequent Tek-Tips...we've missed you, man!

Mufasa
(aka Dave of Sandy, Utah, USA)
[I can provide you with low-cost, remote Database Administration services: see our website and contact me via www.dasages.com]