Comments
Sort by recent activity
@Sergio R
Downgrading – and being stuck there – is not an option. So,
I am left with only one option -- changing history. I have to tell
you, this is at the very least unsatisfying and possibly just downright wrong.
On a (slightly) more positive note, now that I’ve made the decision to go to the dark side
(i.e., changing historical records), I am relieved to find that we only have
one unnamed constraint in our database. Still, this is an annoyance that
should never have happened.
Red Gate should consider the impact that bug
fixes like SCA-2637 have on their customers. Sometimes doing the right thing
from a product feature perspective (i.e., preventing unnamed constraints) is
not the right thing to do for your customers -- without whom Red Gate would not be so successful. Perhaps an introduction of this as a warning that later escalates to an error would have been the kinder, gentler and more customer-friendly approach. [image] / comments
@Sergio R
Downgrading – and being stuck there – is not an option. So,
I am left with only one option -- changing history. I have to tell
you, this is at the very least unsatisfying and possibly j...
This morning, I updated VS2019 to v16.4.5 and immediately afterwards, I updated SCA to v4.2.20064.1605. Now, my SCA database projects won't build or deploy. The error messages is as follows. c:\path\to\semver\folder\001_MyMigrationScript.sql(7,49): Error: : A constraint name must be specified (before the constraint definition eg. CONSTRAINT [MyConstraintName] DEFAULT (0)). This is needed in order to ensure that database builds are deterministic. This error message is in an old migration script that has already been deployed to production. It is complaining because there is a PRIMARY KEY clause on an identity column rather than a separate CONSTRAINT [PK_TableName] PRIMARY KEY (ID) clause with an explicit name. Editing the migration script will not change the database since the script will not be deployed again. Besides, changing an historic migration script goes completely against the purpose of a migration-script based approach anyway, doesn't it? @Diogo , you reponded to @ilundhild saying "...using constraints with system named (sic) for constraints is a bad practice..." OK. We get that. However, SCA should not -- and, indeed, cannot -- suddenly declare that things that happened in the past must be fixed before moving forward. This breaks the DevOps flow. I am working on a hotfix that I need to get out the door quickly and I can't even build my database project? Yikes! How do we get a fix for this immediately, if not sooner? / comments
This morning, I updated VS2019 to v16.4.5 and immediately afterwards, I updated SCA to v4.2.20064.1605.Now, my SCA database projects won't build or deploy. The error messages is as follows.c:\path\...
I am having this same issue. No matter what I do -- reboot, uninstall, reinstall -- I cannot get the Redgate Client Service to start. It just terminates immediately. When I follow the steps recommended by Redgate Support -- using netsh http add iplisten 127.0.0.1 -- netsh reports "The file handle is invalid". In fact, no matter what command I give to netsh -- even the show command -- gives me the same result. Starting to think something is rotten in Denmark (Windows), but I've scanned with anti-virus and anti-malware several times with nothing found...
/ comments
I am having this same issue. No matter what I do -- reboot, uninstall, reinstall -- I cannot get the Redgate Client Service to start. It just terminates immediately. When I follow the steps recomm...