Comments

1 comment

  • Avatar
    Jason Shangold

    Even though this is not an explicit option, the functionality already exists.

    1. Start the bulk editor and select at least a UDP as property type.
    2. When applicable (i.e. when not deleting all values for a specific UDP): Use the Enter filter text box to filter the lines you need, and/or sort the result in the Bulk Editor to focus on the UDP values you need to delete.
    3. Select a row in which the UDP is empty (or manually empty the UDP value in one row, an then select the row)
    4. In the selected row right click on the empty UDP cell (it is important to have the complete row selected!!!!) and then select the first option: Copy this cell (....). Do not use the second option (copy this cell as text)
    5. Now select the rows from which you need to delete the UDP value (or select all rows when applicable).
    6. Right click above a cell of the UDP column (within the selected rows)
    7. Now select Remove <UDPName> in all selected rows

     

    Refer to my presentation on the Bulk Editor for more explicite descriptions: BeNeLux Modeling User Group 2014-06-24 ERwin Bulk Editor.pdf

     

    Since this is already existing functionality, for now I vote against this idea.

    • Don_Tonner

      The title of this idea and the description are describing two different things.  The title says "bulk delete UDP values", but the text describes deleting UDP entries, not values.  The text specifically mentions the UDP editor as well as deleting one entry at a time.  It is this feature that needs fixing.

       

      I am constantly copying and comparing one model with hundreds of UDP's to another model with only a handful of UDP's.  Unfortunately, the model with only a handful of UDP's gets contaminated with the several hundred UDP's and I must delete the unwanted UDPs over and over again.  This is due to ERwin's behavior of assuming one would want both models to have the merged set of UDP's.

       

      The UDP editor forces you to to click in a box and press the delete button.  So I need to make hundreds of mouse clicks precisely inside a box then delete and confirm.  Then I need to switch from Attribute to Entity, etc to get all the various kinds of UDP's.  Then I need to switch from Logical to physical and repeat for Column and Table, etc.  This is a painful process! 

      • GarryG

        This  goes way way back to the ERwin 3.5.2 days when UDPs were mart level objects and cuased nothing but pain.  Library and mart level obhjects inheritance went a way in 4.0 but it still seems that just exposing one model to another without doing any importing of UDPs at all, still contaminates the clean model withthe UDPs that are not wanted.

         

        I think that reather than just allowing the bulk delete of after the fact polution (symptom) that CA should fix ERwin to import UDP's only when done so explictly (the disease). If I don't ask for them to be included in a moel to model compare, do NOT automatically put them in.

         

        Would this not make more sense than having to always undo  Something you did not ask for?

         

        I think you are asking to solve the wrong problem.

        • Don_Tonner

          Garry, totally agree, I will add another idea to allow me better options when CC'ing or synchronizing a model.  Right now it is the same annoying process.  I have to individually check each of the hundreds of properties that I don't want to be migrated.  Also, I believe the UDP's are migrated if you cut and paste an object from one model to the next, and perhaps other mysterious ways as well!

           

          I will still like to have a bulk delete of UDP properties for the cases when supporting existing models.

          • TheovanWestrienen

            I support Garry's idea as well. Why are UDPs not part of CC just like all other objects and properties? May be because UDPs are not regarded as objects within ERwin, but as properties only.

            When look at attributes: htey can be defined using Domains, Validation Rules, Deafutls etc. But the UDP that qualifies is not an object.

             

            May be when we are going to put forward ideas about UDPs, we shoudl really consider the architecture behind it.

            I would prefer a UDP with the same to be the same UDP. Currently this is not the case: UDPs are dfined per objecttype (Entity, Attribute, etc).

            When UDPs are defined as objects, it would be way easier to include them in the CC, but also in the ODBC based reporting.

             

            Ever experienced that an ODBC  query which included UDPs cannot be executed on a model whcih does not contain that same UDP? Turn UDPs into column, so that you can include UDPs using left outer joins, and queries will robust enough to be executed on any model.

             

            Let's create a good idea together!

Please sign in to leave a comment.

Powered by Zendesk