"Generate in DDL" checked back after Export DDL

I have a table COUNTRY in a relational model with "Generate in DDL" flag unset. When I export the model with "File > Export > DDL File" the flag is set back and table is exported.
1) Is there a way to "convince" Data Modeler to leave the "Generate in DDL" flag unset and do not export the table?
2) Is this a bug?
There is a Foreign Key to table COUNTRY with the "Generate in DDL" flag set, but I would say this should not change the flag.

I found the problem. When I do "File > Export > DDL File" , then Generate a small window shows with ticks for:
- Whole model
- - Assigned to Schemas
- - Not Assigned to Schemas
- - Schemas
- - Structured Types
- - Collection Types
All are selected and I only need to export objects "Not Assigned to Schemas". If I untick the "Whole Model" then I tick only "Not Assigned to Schemas" it will set all the tables/objects from the model, without using the "Generate in DDL" flag. More than this, it will set back the "Generate in DDL" flag for all objects in the model. Imagine that I have 100 objects into the model, how is to need to tick back the "Generate in DDL" flag for 30 objects of 100 all the time. This is an annoying bug if you agree.

Similar Messages

  • Shaky play back after export

    The play back in imovie was fine. I then exported and the play back became very shaky. Even now after ecporting,  the play back with in imovie is shaky as well. Any suggestions?

    Hi(Bonjour)!
    Did you render your final sequence before monitoring?
    JES deinterlacer can does a great job with movie speed, and many other things.
    Look at:
    http://www.xs4all.nl/~jeschot/home.html
    See the demo movie at:
    http://www.xs4all.nl/%7Ejeschot/slomotests-JES-DEinterlacer-vs-imovie.mp4
    You have to export your clip before using JES as an external application.
    Set your speed, export from JES and import in FCE browser.

  • Getting message about having LR5 already open SO I need to know how to get my pictures back-after export.

    Hi,
    I have been working on photo's and doing the export the laptop freezes up on me, so I have to shut down everything and re-open.  When I go to open LR5 back up I get an error message saying that there is LR already open and that I have to open a new folder - Since I have editing all (about 900 pictures) - is there a way of getting those back Instead of having to RE-DO all of them.  Which is what I am **** right now and it is VERY hard for me.
    I would Love to get a answer on how I can get the photo's back instead of having to re-do all of them again.  THIS has happening a few times to me now and I don't like it.
    I hope that this makes sense - I would just love an answer..

    okay Error message is as follows - pop up window has confirm on the top of
    it.  The lightroom catalog named "Lightroom 6 Catalog" cannot be opened
    because another applications already has it opened.  Button Choose a
    different catalog, Continue or exit.  I have hit all the buttons before and
    the ONLY thing that works is to Choose a different catalog and open a new
    one?
    Might I be able to get my originals photo's back??  the ones that I have
    edited already???

  • DM 2.0 - No DDL at all after removing Table Constraints

    Hi,
    I'm using SQL Datamodeler 2.0 build 584
    When trying to generate DDL from my relational model (when physical model opened) nothing is generated.
    (after clicking Ok in window DDL Generation Options window DDL File Editor stays empty)
    If I close the physical model and try again, now the DDL is generated.
    This is all occuring after I had to make a couple of datamodel changes including the removal of two Table Constraints.
    Previously I could generate without a problem.
    Looking at the table constraints (after seeing the log-file) I see that the Table constraints are removed m the relational model but not from the physical model.
    When attempting to remove these table constraints from the physical model (delete in right-click menu) nothing happens.
    Anyone who knows what is going on?
    Enrico
    Logfile:
    2011-02-11 15:10:09,344 [AWT-EventQueue-0] ERROR DDLViewer - DDLViewer
    java.lang.NullPointerException
         at oracle.dbtools.crest.exports.ddl.oracle.v10g.SSBTableOraclev10g.appendTableLevelCheckConstraints(Unknown Source)
         at oracle.dbtools.crest.exports.ddl.oracle.v10g.SSBTableOraclev10g.doAppend(Unknown Source)
         at oracle.dbtools.crest.exports.ddl.SQLStatementBuilder.appendTo(Unknown Source)
         at oracle.dbtools.crest.exports.ddl.SQLStatementBuilder.appendTo(Unknown Source)
         at oracle.dbtools.crest.exports.ddl.SQLStatementBuilder.appendTo(Unknown Source)
         at oracle.dbtools.crest.exports.ddl.SQLStatementBuilder.appendTo(Unknown Source)
         at oracle.dbtools.crest.exports.ddl.SQLStatementBuilder.appendTo(Unknown Source)
         at oracle.dbtools.crest.exports.ddl.SQLStatementBuilder.appendTo(Unknown Source)
         at oracle.dbtools.crest.exports.ddl.DDLGenerator.appendDDLFor(Unknown Source)
         at oracle.dbtools.crest.swingui.ddl.DDLViewer.ddlPreview(Unknown Source)
         at oracle.dbtools.crest.swingui.ApplicationView.setDDLViewerVisible(Unknown Source)
         at oracle.dbtools.crest.swingui.diagram.relational.TableDiagramCell$4.actionPerformed(Unknown Source)
         at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
         at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
         at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
         at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
         at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
         at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1225)
         at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1266)
         at java.awt.Component.processMouseEvent(Component.java:6134)
         at javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
         at java.awt.Component.processEvent(Component.java:5899)
         at java.awt.Container.processEvent(Container.java:2023)
         at java.awt.Component.dispatchEventImpl(Component.java:4501)
         at java.awt.Container.dispatchEventImpl(Container.java:2081)
         at java.awt.Component.dispatchEvent(Component.java:4331)
         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4301)
         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3965)
         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3895)
         at java.awt.Container.dispatchEventImpl(Container.java:2067)
         at java.awt.Window.dispatchEventImpl(Window.java:2458)
         at java.awt.Component.dispatchEvent(Component.java:4331)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
         at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
         at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

    then you have to remove it manually from XML file in physical model:
    1) check the ID of table with removed check constraint (in relational model - table dialog, Summary page)
    2) find related file in physical model - <ID in step1>.xml - it should be located in path like this one - rel\1\phys\D9582E4E-2ED963CB9D32\Table\
    there is another file in path like this "rel\1\table" - this is for relational model
    3) find table constraint section in XML file
    it should look like this:
    <storage_object type="TableCheckConstraint" id="B868DAE9-1859-A695-7969-A819F29F568C">
                   <name>TABLE_2_CK</name>
                   <comment></comment>
                   <notes></notes>
                   <alter type="created">
                        <user></user>
                        <timestamp>2011-02-11 18:37:27</timestamp>
                   </alter>
                   <alter type="changed">
                        <user></user>
                        <timestamp>2011-02-11 18:37:27</timestamp>
                   </alter>
                   <properties>
                        <parameter name="object.property.auto.ConstraintID" value="77C506AB-6665-3E79-66D2-6E152BDB1E9B" />
                        <parameter name="object.property.auto.ConstraintName" value="TABLE_2_CK" />
                        <parameter name="object.property.auto.Deferrable" value="NO" />
                        <parameter name="object.property.auto.Enable" value="YES" />
                        <parameter name="object.property.auto.ExceptionsTable" value="NO_OBJECT" />
                        <parameter name="object.property.auto.GeneratedInRDBMS" value="false" />
                        <parameter name="object.property.auto.Initially" value="IMMEDIATE" />
                        <parameter name="object.property.auto.LongName" value="TABLE_2_CK" />
                        <parameter name="object.property.auto.MarkedGenerate" value="true" />
                        <parameter name="object.property.auto.Name" value="TABLE_2_CK" />
                        <parameter name="object.property.auto.NameHasQuotes" value="false" />
                        <parameter name="object.property.auto.RawObject" value="false" />
                        <parameter name="object.property.auto.Table" value="5FEBE67C-6B01-174B-EF13-276A47FE019C" />
                        <parameter name="object.property.auto.Validate" value="YES" />
                        <parameter name="design.owner" value="test_table_constr" />
                        <parameter name="object.existsinrepository" value="true" />
                   </properties>
              </storage_object>
    4) remove definition, save the file
    5) repeat with other involved tables
    Philip

  • BUG: Export DDL and Data fails for mixed case table/column names

    Hi there,
    I have found a bug in SQL Developer. See details below.
    Description:
    When "Export DDL and Data) function is used on a table/columns not named in UPPERCASE, sql generated by SQL Developer is invalid.
    Steps to reproduce:
    - open SQL Developer, connect to DB
    - make a table named "lowerCase" (in double quotes, so it won't be automatically changed to capital letters)
    - you may also add some columns, for example "lowerCol1", "UpCol2", ALLUPCOL3
    - add some data rows to the table
    - choose Tools -> Export DDL and Data
    - check exporting of tables and data, on "filter" tabs choose your "lowerCase" table
    - press "Apply"
    Error:
    Generated SQL contains invalid INSERTs: mixed-case table and columns are referenced without obligatory double quotes, which yields an error when generated script is executed (see below, relevant line is underlined)
    -- DDL for Table lowerCase
    CREATE TABLE "DBO_HT"."lowerCase"
    (     "lowerCol1" VARCHAR2(100),
         "UpCol2" VARCHAR2(100),
         "ALLUPCOL3" VARCHAR2(100)
    -- DATA FOR TABLE lowerCase
    -- FILTER = none used
    -- INSERTING into lowerCase
    Insert into lowerCase (lowerCol1,UpCol2,ALLUPCOL3) values ('lc','uc','auc');
    -- END DATA FOR TABLE lowerCase
    Remarks
    SQL Developer: version 1.2.1, build MAIN-32.13
    Oracle DBs: 9.2 & Express
    OS: Windows 2000 Professional
    If you need any more details/testing, let me know. I'd really appreciate a quick patch for this issue...
    Alternatively, do you know of any other simple way of copying a single database (it's called a schema in Oracle, right?) from one computer to another? Possibly something so simple like detaching->copying->reattaching mdf (data) files in SQL Server... I thought that this "Export DDL&Data" function will do, but as you can see I couldn't use it.
    I just need a simple solution that works - one operation on source to stuff, get the resulting files to other computer and one operation to have it running there... I think that such scenario is very basic, yet I just can't achieve it and I am simply not allowed to spend more time on it (read: our test project fails, my company rejects my "lobbying" and stays with MSSQL :/ )
    Thanks a lot & bye

    Thanks for your reply.
    ad. 1)
    You're right. I just wanted to give some very short feedback on my experiences with SQL Developer, so I didn't think starting new threads would be necessary, but as I was writing it became much bigger than I initially planned - sorry about that. I will make proper threads as soon as possible. Having "Edit post" button on this forum would also be useful.
    ad. 2)
    Generally, you're right - in most cases it's true that "switching DBMS is a major commitment" and "you will produce terrible code" if you don't learn the new one.
    However, I think that you miss one part of market here - the market that I think Express is also targeted on. I'd call it a "fire&forget databases" market; MySQL comes to mind as possibly most common solution here. It's the rather small systems, possibly web-accessed, whose data-throughput requirements are rather modest; the point is to store data at all, and not necesarily in fastest way, because given the amount of data that is used, even on low-end hardware it will work well enough. What's important here is its general ease of use - how easy is to set up such system, connect and access data, develop a software using it, how much maintenance is needed, how easy this maintenance is, how easy are the most common development tasks as creating a DB, moving a DB from test to production server etc. There, "how easy" directly translates to "how much time we need to set it up", which translates to "how much will the development will cost".
    Considering the current technology, switching the DBMS in such systems is not necesarily a major commitment and believe me that you will not produce terrible code. In many cases it's as simple as changing a switch in your ORM toolkit: hibernate.dialect = Hibernate.Dialect.OracleDialect vs MySQLDialect vs MsSql2005Dialect
    Therefore, in some part of market it's easy to switch DBMS, even on project-by-project basis. The reason to switch will appear when other DBMS makes life easier => development faster. From that point of view, I can understand my colleagues giving me an embarassing look and saying "come on, I won't read all these docs just to have db copied to test server". And it doesn't mean "they are not willing to learn anything new", it's just that they feel such basic task should have self-explaining solution that doesn't require mastering any special knowledge. And if they get such simple solutions somewhere else, it costs them nothing to change the hibernate dialect.
    I think Oracle did the great job with introducing the Express to this "fire&forget" market. The installation is a snap, it just works out of the box, nothing serious to configure, opposite to what I remember from installing and working on Oracle 9 a few years ago. In some places it's still "you need to start SQL*Plus and enter this script", but it's definitely less than before. I also find the SQL Developer a great tool, it can do most of what we need to do with the DB, it's also much better and pleasant to use over Oracle 9 tools. Still, a few basic things still require too much hassle, and I'd say taking your schema to another machine is one of them. So I think that, if you do it well, the "schema copy wizard" you mentioned might be very helpful. If I was to give any general advice for Express line of DB/tools, I'd say "make things simple" - make it "a DB you can't see".
    That's, IMHO, the way to attract more Express users.

  • EXPORT DDL in 1.0.0.14

    I am trying to export the DDL for a particular table. Option is not generating any script into the file.
    Oracle 9.0.2.4/Linux AS

    Well, I had 20 minutes this morning to install and then get to work! To be honest, I wasn't holding my breath as I never saw a resolution posted in the Beta NG regarding many of us crashing when trying to access the library. Imagine my delight when I could access the Library! I just grabbed a rejected RAW image from a shoot I did a few nights ago (I had manipulated these in ACR at that time)...developed it and then hit the Export button. Crash.
    I reopened and used Export previous settings (and was impressed that my develop settings were presereved). This worked and I got a jpg out.
    I went back to Export button. Crash.
    Export previous always works, but Export always crashes. Thats just not gonna cut it, because I have no access to export options.
    Very disappointing.

  • SQL Tab & Export DDL Crapped Out in Version 1.1.3

    SO now the SQL tab for a table and the Export DDL option under the Tools menu are not working. The Export DDL option does nothing short of error our when trying to select individual options. (Getting a table or view does not exist error) The SQL tab for tables now no longer shows the associated constraints and in some cases no indexes either. The previous version didn't seem to have these problems. I really think the things that were working need to be verified to not be broken before releasing a new version. As an end user it's pretty frustrating to lose functionality when you think you are gaining new features.
    OS Version: Windows XP SP2
    Oracle DB: 10.1.5

    tnolte,
    I'm going to stick to this thread to respond to your queries.
    I see from (Re: [1.1.3.27.66] create ddl statement that you are running into the ora-942 errors. No-one in that thread mentions that they have switched to the latest release of SQL Developer, i.e. 1.2. Though both you and MRM posted after we released 1.2., so I assume you are. If not, that's a good place to start.
    Please can you confirm, that you are on 1.2 and that you are still running into this error? As mentioned we did have logged and now fixed, the ora-942 errors you mention, so I'd like to track down your specifics. It looks like a permissions issue.
    In terms of the new Export DDL:
    1. We had a request for a 1 button click to export everything for a single schema. To do this, after you have specified the files name and schema, all you need to do is click Apply and all objects, with all the data will be exported.
    So this is: Set file name, select schema, Apply.
    2. To export a specific category, I start by unchecking "Export Object Types", this unchecks all and I can then check only those I require, say tables and sequences. Now if I select Apply, ALL Tables and ALL sequences for that schema are exported.
    So this is: Set file name, select schema, uncheck Export Object Types, Check specific object type categories, Apply.
    3. Now, if you want to only export certain, say Tables or Sequences then use the filter tabs. The first is Filter Objects.
    If my Connection is for HR and I want to export HR objects, then there is no privilege issue:
    After you have taken the steps in #2 above, go to the Filter Objects tab, make sure that the user is HR at the top of the left hand panel and then click GO. (You can use the Object Type drop list on the right to filter for object types.)
    Shuttle the objects you want to the right and repeat for the next object type.
    If, your connection is HR, but you want to export[i] OE objects, and you have read/select access, then only those objects you have access to will display.
    If your access is HR, but you want to export object you have no access to, no objects are displayed.
    Is the ora-942 displayed for all your connections? Can you try another connection? Of all my connections, one displays the 942 and I will have a developer look into that. There does not appear to be a permissions issue.
    One last thing. If you just want to export the DDL of a selection of tables, expand the Tables node, ctrl select the tables you want the DDL for and use the context menu. There is a new Export option that allows you to export the tables to file, clipboard or the worksheet.
    Hope this helps.
    I will be doing a blog entry on this, this evening.
    Sue

  • 3.0.0-665 - Export DDL is empty

    I have a relational model in DM and select menu Export / DDL File.
    I leave the selection Oracle Database 11g and click Generate.
    In the new dialog I leave everything as is (all tables and other items selected) and click OK.
    The result is just some comments:
    -- Generated by Oracle SQL Developer Data Modeler 3.0.0.665
    -- at: 2011-02-24 18:45:45 CET
    -- site: Oracle Database 11g
    -- type: Oracle Database 11g
    -- Oracle SQL Developer Data Modeler Summary Report:
    -- CREATE TABLE 0
    -- CREATE INDEX 0
    -- ALTER TABLE 0
    -- more here, I deleted for brevity
    -- DROP TABLESPACE 0
    -- DROP DATABASE 0
    -- ERRORS 0
    -- WARNINGS 0
    With some other model, it works.
    Any idea what to look for?
    I also tried Oracle SQL Developer 3.0 Early Adopter 4 (3.0.03.97), but it is the same there too (just comments are created).
    I also tried to export just one table, but the result is same, just the above comments.
    Regards,
    David

    Thanks for the picture. That all looks fine. Its contents tells me that you have not got the relevant Physical Model open. (If the Physical Model is open, the Tables do not appear on the "Tree View" tab that is shown in your picture; instead you need to go to the Tables tab to see the list of Tables.)
    Physical Models allow you to provide additional information relevant to a specific database type (e.g. Oracle 10g or 11g). Physical Models appears in the Data Modeler Browser as a node below a specific Relational Model.
    To create one you can select "New" on the right-click drop-down menu for Physical Models. Import from Data Dictionary will also create a Physical Model of the relevant type.
    Reopening a saved Design does not automatically reopen its Physical Models; nodes for those that are included in the saved design will appear as a component of the Physical Models node, but to open one you need to select "Open" from the right-click drop-down menu for the relevant physical model.
    David

  • SQL Developer 3.2 - Export DDL challenge

    Hi,
    I would like to Export DDL for approximately 300 of 1000 objects in a schema.  I have the names of all required tables for which I'd like to get the DDL in a table in my personal schema.  Is there a way that I can use this table as a driver for the built-in Export DDL utility or will I need to either go to the schema browser and hand-pick each of the 300 tables and/or from the Tools-Export DDL "Specify Objects" window?
    I would like to make this more automated so that I dont have to keep clicking, scrolling, clicking my way through the list of required objects.  Any thoughts are appreciated, thanks.

    1008686 wrote:
    Hi,
    I would like to Export DDL for approximately 300 of 1000 objects in a schema.  I have the names of all required tables for which I'd like to get the DDL in a table in my personal schema.  Is there a way that I can use this table as a driver for the built-in Export DDL utility or will I need to either go to the schema browser and hand-pick each of the 300 tables and/or from the Tools-Export DDL "Specify Objects" window?
    I would like to make this more automated so that I dont have to keep clicking, scrolling, clicking my way through the list of required objects.  Any thoughts are appreciated, thanks.
    There is no way to use sql developer to do that.
    You can:
    1. do it manually as you suggest
    2. do it manually by writing a script that makes the appropriate DBMS_METADATA calls
    3. use expdp to extract the metadata and create a DDL file.
    The full DDL for a table will include a lot of components that many people don't even want, for example storage clauses.
    The bigger issue you should address is why you don't already have the DDL to begin with. Best practices are to create the DDL and keep it in a version control system; not extract it after the fact.
    I suggest you use the EXPDP utility to extract the DDL into a file so that you have it for future use.
    If you plan to write a script there are plenty of examples on the web that show how to do that. Here is one:
    http://www.colestock.com/blogs/2008/02/extracting-ddl-from-oracle-2-approaches.html

  • [4.0] Incomplete sort for objects in DDL when using Database Export or "quick DDL"

    As far as I could see, a similar problem has been reported for earlier versions of SQL Developer, but still seems to apply for some parts in 4.0.0.13.80 under Windows7 64bit with JDK 1.7.0_45 64bit ...
    Currently not all objects in a generated DDL using "Quick DDL" or "Tools - Database Export" are sorted evenly ... tables and foreign key constraints seem to be sorted, but common constraints are not.
    This is rather annoying when trying to compare the generated scripts of two databases. Or trying to detect changes over lifetime (SVN etc.).
    Or is there an option for this I could not find/see so far?
    example output from database export of SQLDev 4.0.0.13.80 on the same machine, within some minutes, no configuration change, for a local and a remote database ...
    from local:
    Questions:
    why are there blank lines added for the local database
    why aren't the grants in the same order
    local database
    remote database
      GRANT DELETE, INSERT, SELECT, UPDATE ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "ACCESS_ROLE_FOR_SCHEMA_3";
      GRANT REFERENCES ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "SCHEMA_3";
      GRANT REFERENCES ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "SCHEMA_4";
      GRANT SELECT, REFERENCES ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "SCHEMA_5";
      GRANT SELECT, REFERENCES ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "SCHEMA_6";
      GRANT SELECT ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "SCHEMA_7";
      GRANT REFERENCES ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "SCHEMA_3";
      GRANT REFERENCES ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "SCHEMA_4";
      GRANT SELECT, REFERENCES ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "SCHEMA_5";
      GRANT DELETE, INSERT, SELECT, UPDATE ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "ACCESS_ROLE_FOR_SCHEMA_3";
      GRANT SELECT, REFERENCES ON "FOREIGNSCHEMA"."TABLE_FOR_GRANT" TO "SCHEMA_6";
    remark: missing SCHEMA_7 is okay, because it is not yet on the remote database
    Similar applies to non foreign key constraints, where the unsorted output is even worse ...
    Message was edited by: stueckl

    Did you ever figure out why SQL Developer isn't exporting the NOT NULL attribute of columns?
    I'm running into that on a 9i database, but not on 11g.
    Skip

  • How to reconfigure and restart GoldenGate Replication from MySQL to Oracle after a DDL operation on the source

    I succesfully configured and performed the goldengate replication from MySQL 5.1 to Oracle XE 11g using GG 11g as per
    http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/goldengate/11g/GGS_Sect_Config_UX_MSQ_to_UX_ORA.pdf
    After replication was successully started working I added a new column to one of the test tables TCUSTMER
    ALTER TABLE TCUSTMER ADD COLUMN ADDRESS VARCHAR(64) DEFAULT NULL;
    And inserted another row in the same table.
    INSERT INTO TCUSTMER VALUES ('CLARK', 'CLARK BOATS', 'REDWOOD',  'CA', 'Test Addresss1');
    As soon as I did that the replication broke.
    2015-04-16 17:42:44  ERROR   OGG-00146  VAM function VAMRead returned unexpected result: error 600 - VAM Client Report <CAUSE OF FAILURE : Table Metadata Altered cause
    WHEN FAILED : While processing table map event in log processor
    Then I reverted the DDL change back to original
    ALTER TABLE TCUSTMER DROP COLUMN ADDRESS;
    and tried to run the replication again
    But it is not starting as before.
    What should I do to move forward with same setup.

    Hi ,
    Whenever you do a DDL change in the Source table, you have to make the same changes in the Target side also. Then recreate the Definition File, copy it to the Target side and Start the GoldenGate processes.
    1. Add the column in the Target side.
    2. Recreate the Definition File and copy it to the Target side.
    3. Recreate the Replicat process in the Target side and try to start it.
    Hope this works..!!!!!!!! Any other suggestions friends????????
    Regards,
    Veera

  • Re: Can't do Export - DDL Script

    Greetings!
    I am currently using Build 1.1.0.23 Build Main-23.64 against a 9i database.
    I too am unable to get the Export->DDL to work. It creates the "export.sql" file, but the contents are empty. I am getting the following error message:
    DBMS_METADATA is unable to use TABLE_EXPORT to generate sql.
    It tells me to test by entering the following sql statement:
    select dbms_metedata.get_ddl('TABLE', 'DUAL', 'SYS') from dual;
    This fails:
    ORA-31603: object "DUAL" of type TABLE not found in schema "SYS"
    I'm no expert, but this looks like a fairly severe bug. I've followed the thread, but I haven't seen anything mentioned about a patch/fix.
    Anyone know if there is something out there on the horizon?
    Thanks, John

    What version of Oracle 9i are you running?
    I am guessing here, but I think the Oracle 9i databases available for download have to be patched. However, I think these patches are only available via MetaLink which requires licenses and a current paid contract.
    I think people running what is available for Oracle 9i download have the issues while the patched version of the 9i database works. Is my thinking correct here?
    What is the minimum patch point release to get Oracle SQL Developer to run out-of-the-box?

  • EA2 Export DDL - Save to file issues

    Hi,
    Export DDL/Save to file, defaults a "/" as file name.
    After you have saved a file in a directory the directory is not memorized anymore for the second export, e. g. saving spec and body have to select the same directory twice.
    Juergen

    Hi Juergen,
    Yes, I see the exact same behaviour on my Windows XP SP2 installation when I perform the following steps:
    (1) Right click on a, for example, procedure in the Navigator
    (2) Select "Export DDL > Save to File..." from the context menu
    (3) The "Choose Directory" dialog is displayed, with "/" in the "File name:" field and the starting directory being the root of my C: drive
    Preferred behaviour would be:
    (1) Default "File name:" field to procedure name
    (2) Default starting directory to last used
    Thanks,
    Chris

  • Export.ddl

    Hi friends...
    please anybody can help to solve the following question..this question was ask me in my last interview.
    The attached DDL (“export.ddl”) has been written to work on Oracle 10g,11g
    But it doesn’t work on Oracle 9i, for example when we try to add user it gives the attached error “error.txt”
    The questions are:
    1- Where are the errors (which table, view , trigger …etc. )
    2- How to fix it one by one
    3- The new script after fixing the errors
    the error.txt file is:
    ORA-04068: existing state of packages has been discarded
    ORA-04063: has errors
    ORA-04063: package body "TBS_DPL.SQLSERVER_UTILITIES" has errors
    ORA-06508: PL/SQL: could not find program unit being called
    ORA-06512: at "TBS_DPL.TBST_USERS_US_UID_TRG", line 19
    ORA-04088: error during execution of trigger 'TBS_DPL.TBST_USERS_US_UID_TRG'
    ORA-06512: at "TBS_DPL.TBSP_INSERTUSERDATA", line 47
    ORA-06512: at line 1
    Edited by: JIC on Feb 7, 2012 12:46 PM
    Edited by: JIC on Feb 7, 2012 12:53 PM

    10g and 11g support Data Pump where 9i doesn't. Don't know if they used 9i or not, but ...
    The program unit being called not found is either a new feature in 10g or it's an add on that was not installed on 9i.
    Having the script would help a lot.
    Dean

  • Why there is implicit commit before and after executing DDL Statements

    Hi Guys,
    Please let me know why there is implicit commit before and after executing DDL Statements ?
    Regards,
    sushmita

    Helyos wrote:
    This is because Oracle has design it like this.Come on Helyos, that's a bit of a weak answer. :)
    The reason is that it makes no sense to update the structure of the database whilst there is outstanding data updates that have not been committed.
    Imagine having a column that is VARCHAR2(50) that currently only has data that is up to 20 characters in size.
    Someone (person A) decides that it would make sense to alter the table and reduce the size of the column to varchar2(20) instead.
    Before they do that, someone else (person B) has inserted data that is 30 characters in size, but not yet committed it.
    As far as person B is concerned that insert statement has been successful as they received no error, and they are continuing on with their process until they reach a suitable point to commit.
    Person A then attempts to alter the database to make it varchar2(20).
    If the database allowed that to happen then the column would be varchar2(20) and the uncommitted data would no longer fit, even though the insert was successful. When is Person B going to find out about this? It would be wrong to tell them when they try and commit, because all their transactions were successful, so why should a commit fail.
    In this case, because it's two different people, then the database will recognise there is uncommitted transactions on that table and not let person B alter it.
    If it was just one person doing both things in the same session, then the data would be automatically committed, the alter statement executed and the person informed that they can't alter the database because there is (now) data exceeding the size they want to set it to.
    It makes perfect sense to have the database in a data consistent state before any alterations are made to it, hence why a commit is issued beforehand.
    Here's something I wrote the other day on the subject...
    DDL's issue a commit before carrying out the actual action
    As long as the DDL is syntactically ok (i.e. the parser is happy with it) then the commit is issued, even if the actual DDL cannot be executed for another reason.
    Example...
    We have a table with some data in it...
    SQL> create table xtest as select rownum rn from dual;
    Table created.
    SQL> select * from xtest;
            RN
             1We then delete the data but don't commit (demonstrated by the fact we can roll it back)
    SQL> delete from xtest;
    1 row deleted.
    SQL> select * from xtest;
    no rows selected
    SQL> rollback;
    Rollback complete.
    SQL> select * from xtest;
            RN
             1
    SQL> delete from xtest;
    1 row deleted.
    SQL> select * from xtest;
    no rows selectedSo now our data is deleted, but not committed, what if we issue a DDL that is syntactically incorrect...
    SQL> alter tab xtest blah;
    alter tab xtest blah
    ERROR at line 1:
    ORA-00940: invalid ALTER command
    SQL> rollback;
    Rollback complete.
    SQL> select * from xtest;
            RN
             1... the data can still be rolled back. This is because the parser was not happy with the syntax of the DDL statement.
    So let's delete the data again, without committing it, and issue a DDL that is syntactically correct, but cannot execute for another reason (i.e. the database object it refers to doesn't exist)...
    SQL> delete from xtest;
    1 row deleted.
    SQL> select * from xtest;
    no rows selected
    SQL> truncate table bob;
    truncate table bob
    ERROR at line 1:
    ORA-00942: table or view does not exist
    SQL> rollback;
    Rollback complete.
    SQL> select * from xtest;
    no rows selectedSo, there we have it. Just because the statement was syntactically correct, the deletion of the data was committed, even though the DDL couldn't be performed.
    This makes sense really, because if we are planning on altering the definition of the database where the data is stored, it can only really take place if the database is in a state where the data is where it should be rather than being in limbo. For example, imagine the confusion if you updated some data on a column and then altered that columns datatype to be a different size e.g. reducing a varchar2 column from 50 character down to 20 characters. If you had data that you'd just updated to larger than 20 characters whereas previously there wasn't, then the alter table command would not know about it, would alter the column size and then the data wouldn't be valid to fit whereas the update statement at the time didn't fail.
    Example...
    We have a table that only allows 20 characters in a column. If we try and insert more into that column we get an error for our insert statement as expected...
    SQL> create table xtest (x varchar2(20));
    Table created.
    SQL> insert into xtest values ('012345678901234567890123456789');
    insert into xtest values ('012345678901234567890123456789')
    ERROR at line 1:
    ORA-12899: value too large for column "SCOTT"."XTEST"."X" (actual: 30, maximum: 20)Now if our table allowed more characters our insert statement is successful. As far as our "application" goes we believe, nay, we have been told by the database, we have successfully inserted our data...
    SQL> alter table xtest modify (x varchar2(50));
    Table altered.
    SQL> insert into xtest values ('012345678901234567890123456789');
    1 row created.Now if we tried to alter our database column back to 20 characters and it didn't automatically commit the data beforehand then it would be happy to alter the column, but then when the data was committed it wouldn't fit. However the database has already told us that the data was inserted, so it can't go back on that now.
    Instead we can see that the data is committed first because the alter command returns an error telling us that the data in the table is too big, and also we cannot rollback the insert after the attempted alter statement...
    SQL> alter table xtest modify (x varchar2(20));
    alter table xtest modify (x varchar2(20))
    ERROR at line 1:
    ORA-01441: cannot decrease column length because some value is too big
    SQL> rollback;
    Rollback complete.
    SQL> select * from xtest;
    X
    012345678901234567890123456789
    SQL>Obviously, because a commit statement is for the existing session, if we had tried to alter the table column from another session we would have got
    SQL> alter table xtest modify (x varchar2(20));
    alter table xtest modify (x varchar2(20))
    ERROR at line 1:
    ORA-00054: resource busy and acquire with NOWAIT specified
    SQL>... which is basically saying that we can't alter the table because someone else is using it and they haven't committed their data yet.
    Once the other session has committed the data we get the expected error...
    ORA-01441: cannot decrease column length because some value is too bigHope that explains it

Maybe you are looking for