Aliases Tab

To determine which alias type to use, consider the following:

• If you are working in project A, and create a system alias to the programs directory of project B, then programs in that directory run in the context of project A. That is, the data folder (/data) refers to the data directory in project A.
• If you are working in project A, and create a project alias to the programs directory of project B, then the programs in that directory run in the context of project B. That is, the data folder (/data) refers to the data directory in project B.

• System aliases bring files *into* the project. But with Project aliases, the files are still "in" their own projects, and they can only make references that make sense from there: they can only see paths in their project (and follow aliases found in their project).

• Project aliases are useful if you want to write a Production script in one project that runs some preparation steps in another project. You want those preparation steps to run in the context of the project in which the scripts reside.
• Home Projects should always use project aliases to other projects to ensure that access rules specified in the other project are applied.

• If you move a project that has aliases (or remove and restore a project), aliases break, and you must redefine them. A project has its alias names defined within the project, but the target and target paths are defined on the server. When you uninstall a project, you sever that connection to the server, so the target and target path are lost. When you reinstall the project, you have to re-define them. This is done because there is no way to verify the integrity of target and path when installed on a new server.
• If you need to use a DivePort input table within a project, it is best to create a separate project for the tables and use a project alias not a system alias. This allows you to gain version control of the tables.
• Project aliases are not supported for the two special 6.4 projects (6.4 DiveLine Namespace and 6.4 Production Sandbox). That is, these projects cannot alias folders in 7.x projects—however, the reverse is allowed—7.x projects can alias into the special 6.4 projects.
• ProDiver markers are saved with the current project's path to their source data file (model or cBase). When creating aliases to other projects, it is important to use the project aliases option for that purpose. With a project alias, the DiveLine server can find files within the other project's directory structure. If the same marker is opened through another project's system alias (with a different directory structure in the other project), the source data file cannot be found by ProDiver or other clients.

• When you use a Project Alias from one project to another, it is the access control rules in the target project that control who has access—the idea is you get the same rules no matter how you get to the data.

• Be cautious when copying projects or folders that contain aliases. If you copy an aliased folder, for example by copying an entire project, and paste it into a new project structure, Workbench will treat that as a static copy. You will need to delete that folder and reestablish the original alias.
• If different DiveLine ports share the same dataroot, they also share aliases. Truly separate DiveLine instances do not share a dataroot, which is where project settings are saved.
• Be mindful of which port is used when creating aliases. There may be a disconnect between your typical DiveLine port and where your DivePort is configured. Verify that aliases in your project do not have an error (!) flagged.
• If a project alias does not appear to be behaving as expected and it is pointing at a project created in the current session, try restarting DiveLine.
• When the target of an alias is the local system, the target path can reference a hard drive or a mapped network drive, as long as the DiveLine user account has access. For example:
• Hard: E:\DI_Projects\DI_Hosp\census_hourly
• Mapped: \\FIS\Dept Shared Folders\PressGaney

When creating aliases, you should avoid circular dependencies between projects. In fact, Workbench does not allow you to create a project Alias in project A to project B, then also create a project Alias in project B to project A.

What can you do if your sub-projects need results from the main project and vice versa?

There are two approaches that create better abstractions than co-dependent projects.

1.) Have the sub-projects run Production scripts that wait for the presence of trigger files within the main project. A Production script that is simply waiting for a trigger file does not take up much in the way of system resources.

or

2.) Have a top-level project that is aware of both the main project and the sub-projects. This top-level project can run the main project Production script, and when that is done, run the sub-project scripts, either in turn or in parallel. This has the bonus side effect of giving you a top-level view of everything that is going on.

You can always use several top-level projects to handle cross-project dependencies.