Malcolm Dew-Jones wrote:
> Jack (Jack_at_ss.com) wrote:
> : >
> : > It's only a problem if unwrapped source code gives away stuff you don't
> : > want people to see.
> : >
> : > On the other hand, wrapping source can cause problems if you do not
> : > also include standard version reporting functions in each package or
> : > some equivalent method of determining what exactly is installed, and
> : > you need to support it.
> : >
>
> : Is the 'version reporting functions' refering to some features of the PLSQL
> : language?
>
> No (at least I don't think so).
>
> The following is completely untested, I have no examples with me right
> now. (At work I have one such routine liberally cut and pasted from
> project to project, but I haven't "looked" at it for just as long.)
>
> Assuming you use something like RCS, and check your files in on occasion,
> then, in your source code add something like...
>
>
> FUNCTION Version () IS VARCHAR
>
> BEGIN
>
> RETURN
> '$RCSfile:$ $Revision:$ ' || chr(10) ||
> 'Defines in effect:' || chr(10) ||
> 'EXAMPLE_DEF1: &EXAMPLE_DEF1.' || chr(10) ||
> 'EXAMPLE_DEF2: &EXAMPLE_DEF2.' || chr(10) ||
> ' etc etc ' || chr(10) ||
> '-- end --'
> ;
> END
>
>
>
> Later, you can ask the package what it is
>
> sql> select my_package.version() from dual;
>
>
> Perhaps there's something more elegant, but I have used that for years.
>
>
> --
>
> This space not for rent.
Yes, that's the kind of thing I meant. Standard in the sense that you
would include it in all of your packages. Standalone procedures and
functions are harder. I'm not sure about the best way to handle object
types with bodies but possibly they could include a static "VERSION"
function.
Received on Sun Jul 10 2005 - 18:56:11 CDT
