Leave artifact(s) from SQL Compare command possible?

JDenman

I have a database setup using DLM Automation that will detect changes and create the diff script for packaging in a nuget package in VSTS.

My goal is to use PowerShell to read the sql file that creates users, so that I can [later in my process] notify the user that a new user was created, and to update the password.

Is it possible to leave one or more artifacts from SQL Compare, so that I can parse it?

AlessandroAlpi

Hi @JDenman,

I didn't get it actually. The DLM Automation is installed where? Have you also a SQL Source Control somewhere or are you using just the DLM Automation for packaging? How this is related to reading the sql file for users and SQL Compare? And what do you mean with "Leave artifacts from SQL Compare"?
I'm really sorry for the questions, but I could not understand, and I'd like to do so, because your pipeline made me curious

The database where your're getting the user from is a dev database? Would you like to notify the dev team or you need to compare users with a test/production environment?

cheers,
ale

JDenman

Step 1 of our process runs DLM Automation/SQL Compare to determine what changed in the recent TFS commit, and create a nuget package, that is sent to our Continuous Deployment app (OctopusDeploy).

When the step 'Deploy from package' (in OctopusDeploy) is executed, part of what it does is execute SQL Compare against the target server & database, to determine what changes are necessary to match the version we want to deploy.

I can see from the logs that SQL scripts are created, then executed. But when I look at that temp folder after the step is complete, the files are [naturally] automatically cleaned up. I'm looking for an option in SQL Compare that leaves the files and does not clean them up (I can add a step post to clean it).

AlessandroAlpi

if you're using this, you can setup the following setting:
DLMAutomationDeleteExistingFiles = True

Did you try to change it?

JDenman

No, we're using 'Deploy from package' - since VSTS already build the changes (based on what was checked in) that are needed. I'll explore this as a first step to potentially gaining access to the SQL changes that might be deployed, but it means we'll end up calling SQLCompare twice.