Moving a global to a new database using extended global reference

Say you have a global in one database that you instead want to map from a different database. If you just create a global mapping to the new database, the existing global will become inaccessible because it still lives on the old database. The documentation notes this problem here but doesn't give details on how to fix it.


When you create the global mapping you need to explicitly move the existing global to the new database. This is possible using the merge command along with extended global reference. The environment syntax lets you reference a global in a specific namespace, directory, or remote system. For example, I can reference the ^pbarton global in the USER database with the following syntax:
zw ^|"^^c:\cache\user\"|pbarton
if the USER database lives in the directory "C:\cache\user\".


In order to move this global to the USER-CODE database that lives in the directory "C:\cache\usercode\", I can use the merge command while explicitly specifying the environment in my global references:
merge ^|"^^c:\cache\usercode\"|pbarton = ^|"^^c:\cache\user\"|pbarton

Comments

Neither MERGE nor ^GBLOCKCOPY move the global: they are only copy it, unless somebody KILL it's old instance after copying.

Good point that I forgot to highlight. If you don't kill the old instance, it will sit in the old database without any easy way of referencing it.

I would also like to note that MERGE is extremely slow.

Mike, would you please clarify? Merge is slow compared to what?

John Murray also provided a different solution in this post. You can view globals by database rather than namespace in the SMP. That way you can export a global from one database into a file, then import it into another database. After some digging I found this is actually what the documentation recommends. The advantage of the MERGE is that it's much simpler to do programmatically. I can't speak to the difference in performance.