>Quick question,
>
>If files are referenced using relative paths yet are included in a build, how is the file located during runtime where the paths are not the same as during development?

Depends on the file, and how the reference is actually stored in the object.

The executable is searched first for files that do not have an explicit path or file extension to see if they can be resolved there. The internal reference is used if possible, If the file is not there, the current working directory is searched, followed by the additional directories specified in the SET PATH statement. Relative paths in the SET PATH are resolved relative to the current working directory.

If a file extension that could be omitted is explicitly specified, the current working directory followed by the SET PATH paths are searched. Using the file extension normally implies that an actual file rather than a part of the executable is being referenced.

Relative paths (a file that includes a partial path) is resolved relative to the current drive assignment. A relative path without a drive letter is resolved relative to the current working directory of the current drive. A relative path that includes a drive letter without a fully qualified path is resolved relative to the current folder on the named drive.

In many cases, internal references that we think are relative are actually converted to fully qualified paths, for example in .DBCs. These converted addresses can be changed back to relative addresses by hacking the container to have a relative reference in it. If the container is embedded in your executable, this is not an option, and youmayhave to resort to things like DBSETPROP() and CURSORSETPROP() at runtime to fix up the entries.

References to mapped network drives are inherently dangerous, because there is no assurance that the mapping will be done consistently. If you must specify an absolute network path, a UNC is a far safer alternative, since all systems in a given network should resolve the UNC in the same fashion.