Too much for a comment, but trying something.
From the msdn page of that system table catalog.executions I get:
execution_id - bigint - The unique identifier (ID) for the instance of
execution.
From this article - SSIS 2012 – View Connection Manager Information for Past Executions - I understand that:
SSIS 2012 provides a new system variable, ServerExecutionID, for your
use inside packages, so if you do any custom logging/notifications it
is a good variable to include as it will be a direct pointer to the
catalog views that we’ll use to find connection string information.
... Catalog.executions contains one row per execution. This is where
we’ll filter by execution_id.
With a sample query of:
DECLARE @execution_id BIGINT = 41753; -- Your execution_id/ServerExecutionID goes here.
SELECT e.package_name,
e.start_time,
e.end_time,
e.status,
emc.package_path,
CAST(emc.property_value AS VARCHAR(1000)) AS connection_string
FROM catalog.executions e
JOIN catalog.event_messages em
ON e.execution_id = em.operation_id
JOIN catalog.event_message_context AS emc WITH (FORCESEEK)
ON em.event_message_id = emc.event_message_id
AND emc.property_name = 'ConnectionString'
AND emc.context_type = 80 -- Connection Managers
WHERE e.execution_id = @execution_id;
What I don't see is your ExecutionInstanceGUID in this table.
What I see, though, is this ancient Connect item where there's the following story:
SSIS RunningPackage.InstanceID != System::ExecutionInstanceGUID
though they should be equal.
So my conclusion is that ExecutionInstanceGUID is not related to execution_id, but some InstanceId column, in case you might have one in the SSISDB.
You can reference the local server with a period .
If you have an instance name, too, then use .\instancename
Best Answer
I experienced this problem, and was able to resolve it by disabling a DDL trigger on the SSISDB database for
DDL_DATABASE_LEVEL_EVENTS
. The trigger was trying to write info into another Database.