Why does EG store dataset objects using the library object name?

[ScottBass]

Hi,

I admit, I don't use EG much, but my end users do.  So they have hundreds of saved projects. 

Yesterday I made a change to the metadata, which broke their saved projects.  Luckily, changing it back fixed the issue.

For the sake of this discussion, say I have this library defined in metadata:

Object Name: "My Library"

Object Id:   A5LKTB5E.AY00002D

Libref:      mylib

Path:        C:\Temp\mylib

We recently migrated that library to SPDE, but want to keep the old library object around for a bit (performance comparisons).  So, I changed the old library object to:

Object Name: "My Library - BASE"

Object Id:   A5LKTB5E.AY00002D  (unchanged)

Libref:      mylib_b

Path:        C:\Temp\mylib_base

And created this new library object::

Object Name: "My Library - SPDE"

Object Id:   A5LKTB5E.AY000020

Libref:      mylib

Path:        C:\Temp\mylib_base

IOW, I wanted to transparently migrate the users to the SPDE library, but I also renamed the library objects to make it clear which one was being used.

I was surprised that EG is using the library object *name* as the pointer to the library, and that changing the name would break the projects.  Renaming "My Library - SPDE" to "My Library" fixed the issue with the saved EG projects.

In Base SAS, a dataset is referenced by libref.dataset, so changing the definition of the libref, but not the libref itself, would seamlessly change the datasets being referenced.

If I recall correctly, DI Studio uses the library object id in its jobs, so that changing a library object name in metadata would not break the job.  (I'm going on memory here)

So why is there a third way to reference libraries in EG?  I would have thought either the underlying libref (my preference) or underlying object id (to be consistent with DIS) would have been used.

I'm sure there's a good design reason why the library object name is used, but I can't think of it.  So what is that good reason???

Lesson learned though:  once you create a library object in metadata that is used in EG projects, you're stuck with the name.  So choose wisely .  Of course, the same principle applies to choosing a libref in base SAS programming.

Regards,

Scott

[Doc_Duke]

Often the default name in EGuide is the OS file name for the SAS dataset.  I use LIBNAMEs in Eguide and changing the underlying location just means changing the libref, just like in base SAS.

Doc Muhlbaier

Duke

[twocanbazza]

Yes interesting questions, as you can define two libnames with the same name in Metadata ....

Change one of the names, which one would it use?

Barry

[ChrisHemedinger]

You can use the Migration Wizard (MigrationWizard.exe in the EG application directory) to update your EG projects to have the correct library reference when names/libnames change.

I'm not sure what DI Studio does, but I doubt that it references the metadata ID of the library.  That value is "volatile" and can change when you migrate content from one metadata environment to another, and that's why EG doesn't use it.  Then again, DI jobs are stored in metadata and thus participate in metadata migration, so perhaps it can reference the ID safely.  EG projects are not metadata objects -- they are external files -- and that's why you must use the MigrationWizard to fix them up when a library name or server name changes in your environment.

It's almost a philosophical question. Which is the more "definitive" name: the library object name or the libref?  SAS programs rely on the libref, traditionally (aside from the META engine, which uses the library name).  But clients such as SAS Management Console, Information Map Studio, and even EG show you the library name first, and you must dig to find the libref if it's important to you.

Here's what I do.  These are my general practices as an amateur SAS admin.  Others may have experiences/requirements that conflict with these guidelines.

- if possible, make the library name and libref the same.  But you sacrifice human readability of the library name.

- if they must be different, try to make the libref a derivative of the library name (so that you can guess one given the other).  Example: "Human Resources" (name) -> "HR" (libref).  In many cases, the libref is legacy: you already have production programs that use it.  So your only discretion is in how you provide a "friendly name" on the object.

- do not define the same libref in two different library objects.  Sometimes people do rely on this trick though, partitioning the metadata permissions so that one segment of users sees one definition, while a different segment sees the other.  That's valid, but you must recognize the potential conflict when users overlap these segments.

- likewise, do not use the same library name in two different library objects.  Ideally the management console would make this difficult to do, but I think it is possible to get in this situation.  Because the name (not libref) takes precedence for most metadata-centric operations, having duplicate names can cause confusion, if not serious problems.

Chris