From oracle-l-bounce@freelists.org Thu May 26 12:09:01 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j4QH91vQ031942 for ; Thu, 26 May 2005 12:09:01 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j4QH91Ni031938 for ; Thu, 26 May 2005 12:09:01 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 0E0801B21B0; Thu, 26 May 2005 11:06:03 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14684-04; Thu, 26 May 2005 11:06:02 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 82F011B1DB0; Thu, 26 May 2005 11:06:02 -0500 (EST) Date: Thu, 26 May 2005 11:04:04 -0500 From: "Dan Fink" To: darrell@landrum.com, oracle-l@freelists.org Message-ID: <2513425.1117123444190.JavaMail.root@hotsos01.hotsos.com> In-Reply-To: <20050526153240.9A28C1B1D1F@turing.freelists.org> Subject: RE: 30+ long db_link names and dbms_metadata.get_ddl x-scalix-Hops: 1 X-Client-IP: 4.37.64.164 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit X-archive-position: 20352 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: Dan.Fink@hotsos.com Precedence: normal Reply-To: Dan.Fink@hotsos.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 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@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