Database Reference
In-Depth Information
This is referred to as dot sourcing the scripts, which will pull all the functions and any variables
into the same runtime scope of
IncludeTest.ps1
. Note there is no leading space before the
period and then a space between the period and the ilename. In this case we are expecting
these included scripts to be in the current directory (the
.\
) - not necessarily the directory of
the calling script (
IncludeTest.ps1
).
Usually the included iles will be somewhere else and you may need to provide a full path to
the iles being included, such as:
"C:\Scripts\Oracle.DataAccess.ps1"
Alternatively, you could modify your environment path either more permanently in Windows or
temporarily with PowerShell, as follows:
$env:Path += ";C:\Scripts"
. Oracle.DataAccess.ps1
Finally you might temporarily change directory to a known location using
pushd
and
popd
before and after including the script iles, or use other techniques such as relative pathing
from the script's directory using the
Get-ScriptDirectory
function from the recipe
Filtering and exporting data (Simple)
.
After dot sourcing the script iles,
IncludeTest.ps1
listed the functions in scope using
dir function:
and the results showed the various ODP functions that we deined and
were loaded with the include. If we ran
dir function:
after the script inished executing,
the functions would no longer be available. However, if we ran
IncludeTest.ps1
using dot
sourcing as well (
. .\IncludeTest.ps1
), the functions would still be in scope for use even
after the script inished executing.
The rest of the script remains similar to what we've looked at in previous recipes. One
difference is the use of more shorthand syntax such as
?
in place of
Where-Object
,
sort
instead of
Sort-Object
, and so on. More importantly we've refactored some
existing common functions a bit and added new ones, such as
Load-ODP
, which uses a
ValidateSet
attribute as
[ValidateSet(2,4)]
to ensure that the version parameter
is either
2
or
4
, to load the corresponding .NET framework version of Oracle.DataAccess.
There's more...
Care should be taken when dot sourcing iles as problems can arise. For one, any script level
variables of the included scripts are globally available for
get
and
set
access in the script
they are included into. A careful naming convention should be chosen to ensure it's obvious
what functions do, and that there aren't function name collisions between scripts. Finally,
these functions should generally be generic in nature, with parameters to help prevent making
too many assumptions about the script code using the functions.
Search WWH ::
Custom Search