Re: utl_file

"Neil W. James" <neilNONSPAM_at_familyjames.com> wrote in message news:brnrud$r1q$1_at_news-reader2.wanadoo.fr...

> Howard,
> As I recently implemented usage of UTL_FILE_DIR init.ora feature on a
> 9.2.0.4 XP version (that works like your example), I too was puzzled.
>
> I think the difference can be explained in the actual title of the
> Metalink note - "UTL_FILE_DIR init.ora parameter obsoleted from 9.2".
> That is a true statement, namely that the new directory facility that
> can be selective to the individual user renders the init.ora method
> obsolete.

See below. Technically, it renders it 'deprecated'. "Obsolete" specifically means it's non-functional, and as you concur, that's not true in 9i Release 2.

>
> That is different to saying that the existing method has been removed.
>
> Bit subtle though.
>
> Regards,
> Neil

I agree, Neil. It's just that when Oracle provides a piece of better functionality, but the old one remains functional, they always refer to that as being 'deprecated'. When they declare something to be obsolete, they invariably mean 'it isn't there any more and it won't work if you try to put it back'.

db_block_buffers is officially 'deprecated', because db_cache_size replaces it and has more functionality (it's dynamic, and block_buffers is static), but it can still be used. As can longs and long raws, despite CLOBS and BLOBS providing better features. By contrast, db_block_max_dirty_target is officially obsolete, and can't be set any more at all.

That's always been the way Oracle has described these things, and whoever wrote that Metalink note has not understood the distinction, I think. I'd call it a documentation bug myself, as well as being a pernicious example of people not understanding what words actually mean.

Regards
HJR

-- 
------------------------------------
Oracle insights at www.dizwell.com
------------------------------------