‘ucybdbld -EREPLACE’ should replace object locations too

[Michael A. Lowry]

When loading a transport case usingucybdld -EREPLACE, if an object already exists in the DB, and if the primary folder location of the object in the transport case is different from the primary folder location of the object in the DB, thenucybdbld does not replace the primary folder location in the DB. Instead, the primary folder location of the object in the DB remains as-is. The primary folder path of the object in the transport case will be added as a link in the DB, if it does not already exist.

If one moves an object several times in the source DB, doing a transport to the target DB each time, then the object links will simply accumulate.

In the Automation Engine DB, an object’s location is merely an attribute of the object. Thus, ucybdbld -EREPLACE does not perform a true replacement, because one object attribute (location) is not replaced.

There ought to be a way to make ucybdbld truly replace all object attributes, including the primary folder location.

☙

The best way to solve this problem without breaking existing customers’ processes would probably be to modifyucybdbld so that the user could specify how folder locations should be handled. Here’s one idea of how it might work that covers most possibilities.

---

 

UCYBDBLD [-V[Path and file name]] [-IFile name] [-LLanguage] -B -Cmmmm [-EMode] [-UName/Department] [-GName] [-AAccess] [-MAccess] [-FFolderHandling] -XFile name

...

-FFolderHandling

Determines how folder locations (links) are handled when existing objects are replaced. Valid only when -EREPLACE is also specified. Can be especially important when the folder location(s) of an object in the transport case differ from the object’s location(s) in the DB.

Allowed values forFolderHandling:

MD=Merge, database priority.The primary folder location in the database takes precedence. All other folder locations (whether in the transport case or the DB) will be links. The primary location in the DB is not changed (default).
MT=Merge, transport case priority.The primary folder location in the transport case takes precedence. All other folder locations (whether in the transport case or the DB) will be links.
OD=Only database.No changes are made to the folder locations in the DB.
OT=Only transport case. The primary folder location will be set to the primary folder location in the transport case. Any other folder locations in the transport case will be links. Folder locations found in the DB but not in the transport case will be removed.
PD=Primary location only, database priority.The primary folder location will be set to the primary folder location specified in the database. No new links will be created, and any existing links will be removed.
PT=Primary location only, transport case priority.The primary folder location will be set to the primary folder location specified in the transport case. No new links will be created, and any existing links will be removed.

---

The behavior we are most interested in is OT — in other words, we need a way to instruct the DB load program to completely replace all the folder locations of objects that are replaced, with the location(s) specified in the transport case. If anyone has ideas of how to make ucybdbld work this way, or to achieve a similar result through other means, I would be glad to know about it.

[Pete Wirfs]

 

I have had the same observation/issue.  This is one of the issues that causes us to still do human validation after a transport case import. (which is very stressful on large implementations.)

[Legacy User]

Michael, I like this idea and this very complete request containing all thoughts, i will make sure that product design team is going to have a look at this post, however if you havent done yet, please drop it also as a product suggestion so it arrives there also on the official way.

thank you!

[Michael A. Lowry]

This problem highlights the fragmented and inconsistent approach to moving objects from one UC4 system to another.

• Using the transport case, youcannot specify a target folder location, and if you try to change the location using ucybchng, the original location will remain the primary location anyway.
  
• Using the XML export/import, youmust specify a target location, but cannot copy entire folder hierarchies.
  

[Michael A. Lowry]

In another discussion,Listing objects in a transport case export file, I posted a command that will remove all links from a transport case file. I thought this command might be worthwhile to post it here too.

awk '/^O/{if(seen==0){seen=1;print $0}} !/^O/{if (seen==1) {seen=0} print $0}' $trans > $newtrans

This awk command strips out all links, leaving only primary folder locations. I have tested it, and it works well. It removes links reliably, and it makes no changes to the transport case other than removing links.

That having been said, this is only a partial work-around for the aforementioned limitations of ucybdbld.

In our environment, the only way we could conceivably  fix object locations in the target system using available tools would be to do something like this:

1. Before loading the transport case into the target environment, strip out all links, using the above command.
2. After loading the transport case, for each object that was in the transport case, use the Java APIs to query the target UC4 system object-by-object to get the object’s primary folder location.
3. If the object’s location in the target system is different from the location listed in the transport case file, use the Java APIs again to remove any links the object has, and move the object to the correct target location.

This would be inefficient and messy, but it just might be worth the trouble, if we could eliminate the object links (and their parent folders) that continue to accumulate in our TESTING and PRODUCTION environments.

I would strongly prefer a proper solution from Automic.

[Michael A. Lowry]

We have developed a fix based on the approach I described above. It requires running SearchObject()  for each object in the transport case, and then, for each object whose location differs between the DB and the transport case, a recursive SQL query, DeleteLink(), and MoveObject(). As I said, this is time-consuming and not terribly elegant; but it works.

[Michael A. Lowry]

A (probably wisely) simplified  version of this enhancement was delivered in v11.1, with the new -F command line option for ucybdbld:

                               

-F Folder handling

Defines the behavior of DB Load regarding folders. When objects or linked objects are being replaced, the data of the home folder and the linked objects of the Transport Case are preserved.                     Allowed value = "OT"                     When this value is set, the data contained in the data file of the Transport Case will overwrite already existing objects in the Automation Engine database.

See the v11.1 or v11.2 documentation for ucybdbld.

[Michael A. Lowry]

I discovered this morning that UCYBDBLD -FOT does not work correctly if links to the objects already exist in the target folder.

For example:

Before:
The transport case contains object ABC.JOBS in folder \APPS\ABC\MAIN
In the target system, object ABC.JOBS is in \APPS\ABC\MAIN\SUB1, and a link to the object is in \APPS\ABC\MAIN.

When ucybdbld -FOT is run, it displays these messages:

U0021126 Client '0001': Importing object 'ABC.JOBS ' of type 'JOBS'.
U0021149 Link of object 'ABC.JOBS ' to folder '\APPS\ABC\MAIN' already exists.

After:
In the target system, object ABC.JOBS is still in \APPS\ABC\MAIN\SUB1, with a link in \APPS\ABC\MAIN. In other words, the location of the object remains unchanged.

[Michael A. Lowry]

Sorry, false alarm. I had been mistakenly running an older (v9) version of the DB Load program. The v11 ucybdbld program works correctly.