RE: 30+ long db_link names and dbms_metadata.get_ddl

I wrote a series of scripts that combined the 50% of DBMS_METADATA that worked with custom calls for the 50% that did not. I logged multiple TARs (even more than when I was working on 7.0.? OPS on OpenVMS), turned them into several bugs and railed against the horrible documentation. I really despise it when the conceptual documentation is written by marketing and the user documentation is written by the original programming team. No offense to programmers (I was one once...and still am to some degree), but they tend to write as if they were the audience. They are obviously very smart, but need to remember that we are all not as smart, or at least not as smart in the same areas. I did manage to find some articles on the web about DBMS_METADATA, but it was all a regurgitation of the documentation and not useful at all.   

I played around with the 10gR1 version and found it was living up to it's promise. Much easier to use and you could actually extract a simple schema with one call! I have not used it in a year, so it may have changed substantially. All in all, it is a great little feature. The upside of the 9i version is that I learned a great deal about long -> clob conversion, extracting ddl using hierarchical queries to resolve most dependencies, etc.   

Regards,
Dan Fink   

• Original Message ----- From: Darrell Landrum Sent: Thu May 26 09:32:50 MDT 2005 To: oracle-l_at_freelists.org Subject: RE: 30+ long db_link names and dbms_metadata.get_ddl

Right on about it being buggy! It is a great start to a great tool, but has some gotchas. One example is, in my experience, dbms_metadata extracts the ddl of a materialized view with "enable query rewrite" even if you have it disabled on your materialized view. Not life threatening, but still problematic until you catch on.

--

http://www.freelists.org/webpage/oracle-l
--

http://www.freelists.org/webpage/oracle-l Received on Thu May 26 2005 - 12:09:01 CDT