Scenario: an SSIS package deployed to msdb is accidentally overwritten. The new package was "supposed" to be deployed to a QA server but may have been inadvertently deployed to production. Of course, database objects it depends on were not deployed there, so the package fails miserably as it should.
Short of exporting the existing package and comparing it to its older-version self... is there anything in the msdb database that logs the event of having imported the package?
I'm trying to confirm - or deny - the suspicion. Unfortunately it would have been deployed via a BAT file calling DTUTIL, and the author of that file didn't include anything to log what server was fed into it. No, I don't like it either but keep in mind I'm in a large company with a lot of servers, and two DBA's. We're well divided - the DBA's handle ALL deployments to QA and production, but the method of deployment isn't always in our hands. I've already advised the development team involved to not send us these batch files, we can handle directly deploying the packages ourselves. And I already have plans for a central, file-based SSIS server.
But for now, we have what we have, and I just want to find out for sure if someone accidentally deployed the package to the wrong server. If it were a procedure I could simply query sys.objects and check the create_date or modify_date columns. I'm hoping there's something similar in msdb for a server-stored package. The sysssislog table doesn't appear to have import events logged, and the create_date column in sysssispackages reflects the date the package was created, not imported; and I can't seem to find any other columns in any other tables to show it empirically, either.