ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Copy File With All Dependent Objects to Another Library

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Copy File With All Dependent Objects to Another Library

    Hi all,

    first of all I’m sorry if this question has been answered before. I searched for "dependent" in the forum but didn’t find anything that met my needs.

    What I found was a way to list all dependent objects in a helpful article by Simon Hutchinson.

    My question is, how I can copy a file with all its dependent objects to another library, i.e. logical files, views, indexes, triggers, etc.
    To be more specific: the dependent files should be dependent on the copied physical file in the new library, not the old one.

    In the past, I would use Navigator for i to retrieve the SQL source of all dependent objects, then change the library name in the sources and re-create all dependent objects.
    When moving a whole application with a lot of file objects, I am afraid it’s a task that will cause a lot of hard-to-identify errors.

    I assume that I’m not the only one who has to do this sort of things so I’m hopeful someone has done it before or that there is a system command I’ve overlooked so far.
    Or, someone points me to the forum topic I missed.

    Thanks,
    Markus

  • #2
    I hope my question is not too stupid.

    Comment


    • #3
      Can you explain why you need to do this?

      I suspect the reason that you haven't had replies is simply because no one else has had the need to do it.

      I've done things like this that were specific to the situation. For example, it would hard code the object to duplicate, and hard code building the dependencies in the new library. But I've never written one that figures out all of these dependencoers and figures out for itself how to rebuild them such that it would work in all situations.

      I imagine that I could do something like that if I had to -- but, since I've never had to, I don't have a solution off the top of my head.

      Comment


      • #4
        Thank you, Scott.

        What I want to do is moving files from my development library to test/production and vice versa.
        It worked fine doing it manually until recently, because we only had physical and logical files.
        Since we discovered the possibilities of DDL, files have a growing amount of dependent objects and deploying becomes more complicated.

        Another application is (automated) tests. It would be nice to be able copy objects to a temporary file in a test library that is created on the fly before running the tests.
        So after testing, you start with a fresh state because none of the original files were affected (with the help of strdbg updprod(*no) as mentioned in My RPG Unit Test Journey by Little Blue Monkey ).
        Last edited by Scholli2000; March 20, 2022, 04:42 AM.

        Comment


        • #5
          I've not heard of someone trying to figure out dependencies from the object before.

          Normally, there'd be some sort of file (physical file, Makefile, XML file, ... something ...) that contains a list of dependencies. Typically this would be a part of your change management software, or your home grown system for maintaining your application, and would be kept up-to-date by developers as they develop your application.

          This software would have a facility to rebuild everything that a particular object depends on.

          That's not to say that you couldn't find a way to make your idea work -- a lot of the information (maybe all of it?) is available. But I can't tell you the specifics of how to write it, I haven't done it before.

          Comment


          • #6
            I think you can make a nice tool by using Simon Hutchinson's example along with CRTDUPOBJ or maybe SAVOBJ/RSTOBJ and wrap it up in a command.

            Comment


            • #7
              Thank you both!

              Meanwhile, I learnt that CRTDUPOBJ performed on a view you copy to another library will break the dependency on the old table and requires the table to be in the library the view is moved to. Just like with logical files—to be honest, that’s all I wanted. Now I understand why my question caused a little bit of confusion.

              The SQL generated by the GENERATE_SQL procedure had the library hard-coded in it, which put me on the wrong track.

              (Sorry for the late answer, somehow I managed to not post my answer when I first wrote it)

              Comment

              Working...
              X