Database Release from package - PostUpdate Schema check failed

SvenT

DLM Release is giving me some trouble right now.

I am trying to release a database package to a test environment, which in itself works. However the post-update schema check is failing. I have already run it without transactions and static data. Comparing the decompressed package to the Database afterwards shows no differences using the filter.scpf contained in the package.

Is there a way to get back the difference list, which causes a terminatingException? It would be immensely helpful know WHY the validation fails.

2018-01-04T11:52:54.3968313Z ##[error]System.Management.Automation.CmdletInvocationException: Post-update schema check failed: the schema in the Database Release object (created at 04.01.2018 12:51:59 +01:00) and database 'XXX' on server 'XYZ' are different. ---> RedGate.DLMAutomation.Shared.Errors.TerminatingException: Post-update schema check failed: the schema in the Database Release object (created at 04.01.2018 12:51:59 +01:00) and database 'XXX on server 'XYZ' are different.

Any help would be greatly appreciated

SvenT

Ok.... I found the issues....

I want to write down what I did, to be able to actually trace the errors, and this is only gonna be valid for the VSTS plugins. I'm also gonna rant a little here and there, please forgive that... just read past those parts.

Step by step :

1st: In your VSTS release process, add a variable: System.Debug = True. This will make DLM actually write something useful to the log.

2nd: All the log files, all the to be compared resources, are written to the _work/_temp folder of the VSTS build agent. Once you know that, you can copy those resources out of that temp folder, while your release is breaking to somewhere they do not get deleted. You can do that by writing some c# and file system watcher all that crap out, or you can just press the button a few times and ctrl c, crtl v.

3rd: With the System.Debug = true setting, the exact command line call is logged. Replace that temp folder with where ever you copied over those resources, and run it. If you get the same log out of that, you are good.

4th: Add the following command line switches :
/Report:<file path> /ReportType:Simple

With those 4 easy steps, you actually get told, why the release failed.

In my case, I got 2 tables reported back as a difference. On one, I got a index fill level as a difference, where the fill level was the database default. On the other, I got back a textimage on Primary, which also is a default, so, well, DB defaults that where not explicitly set in the script, where reported back as a difference, while the tables did not get rebuild, since, well, there is no difference, since the missing specification was the DB default. Dear RedGate dev's you might wanna look into that at some point.

In any case, please for the love of god, this has cost me 3 weeks of my live, and this drove me near insanity... Please, for the love of god, please, write up something, put it in the FAQ, and tell people how to get decent error reporting out of DLM when used in conjunction with the VSTS plugin.

I have decompiled the .Net DLL's and read trough the call paths, I have traced every single windows Process.Start event, I have done pretty much everything short of recompiling the decompiled sources to write stuff to a text file on a few method calls.... This really did cost me a LOT of nerve. Please document how to get actually verbose logging out of the DLM toolkit while running it off VSTS.

Once I got that report html file, I called it a day and went for a beer, since now finally after 4 weeks of ripping my hair out, I can actually make a release of that database work. Trust me, I did use google, I read every single piece of documentation I was able to find. Please document that stuff, or make the documentation of this more accessible.

If I see anyone with a red-gate T-Shirt on SQL Bits, you gonna have to buy me a drink.

AlexYates

It is comparing the target DB to the source directory in the DlmDatabaseRelease object, not the original NuGet package.

Try doing that diff and see what shows up.

SvenT

What exactly would be the content of the source directory of the DlmDatabaseRelease Object, if not the \db\state\ content of the NuGet Package? I am a bit confused right now.

AlexYates

Well yes - I would expect them to be the same too - but SQL Compare is throwing a wobbly.

It's just worth being aware that the post-deploy schema check that SQL Compare is performing (and finding differences) is not with the NuGet, it's with the source directory in the DlmDatabaseRelease. I would take a look there to see if it finds something unexpected.

That may reveal in interesting clue and it may also help us to work out whether the problem is running SQL Compare or the creation of the DlmDatabaseRelease.

chris_godfree

I would second (and third and fourth etc) this - I had a pre-update check fail and it took far too long to identify the problem (a simple permissions issue as it happens) even with some help from Redgate. It could have been resolved instantly if the results of the comparison were available. Seems like a very simple thing to add.....

AlexYates

I wouldn't disagree. :-)