Comments
Sort by recent activity
I'm assuming "Ignore user's permissions and role memberships" will apply to all users, not just the Windows ones. Is that correct. / comments
I'm assuming "Ignore user's permissions and role memberships" will apply to all users, not just the Windows ones. Is that correct.
Hi Sergio, Yes, our new dev/test environment is being built in it's own AD Domain. This gives us problems in that the Windows users on the production database will be like Prod\JohnSmith and in the test database will be Test\JohnSmith. We are using SQL Change Automation projects. / comments
Hi Sergio,Yes, our new dev/test environment is being built in it's own AD Domain. This gives us problems in that the Windows users on the production database will be like Prod\JohnSmith and in the...
PeterDanielsCRB said:
What if I hacked it by creating a __MigrationLog table and copying the data over from the dev DB?
That's what I've been doing to get new projects up and running. Clone the prod database to a test server, run the deploy on the clone and then copy the __MigrationLog and __SchemaSnapshot tables to the production box. It's awkward but better than redeploying all the views and sprocs to a busy production server. / comments
PeterDanielsCRB said:
What if I hacked it by creating a __MigrationLog table and copying the data over from the dev DB?
That's what I've been doing to get new projects up and running. Clone...
Here's my feedback, make it stop, it's bloody annoying... / comments
Here's my feedback, make it stop, it's bloody annoying...
@Garth_Martin We used the pre-deployment script to create a stub with just enough of the related db to validate the build. Something like: /*To get around the cross database queries we need to scaffold out the archive database*/ IF (DB_ID('Archive') IS NULL) BEGIN -- create the database CREATE DATABASE [Archive] END GO -- create the objects that we need for validation IF (OBJECT_ID('Archive.dbo.Alerts') IS NULL) BEGIN CREATE TABLE [Archive].[dbo].[Alerts] ( [AlertID] [INT] NOT NULL, [ObjectID] [INT] NOT NULL, ...
/ comments
@Garth_Martin We used the pre-deployment script to create a stub with just enough of the related db to validate the build. Something like:/*To get around the cross database queries we need to scaff...
Test and production DBs are currently on premise, but deployment will only require the same deployment agent as we run for our web/windows service deployments. We are using the hosted build service precisely so we don't have to maintain local build agents and keep them up to date. No-one has time for that, it's the reason we moved from TFS to Azure Devops. I guess I'll have to find a way to script the stub database into whatever instance the Redgate tasks are using for the build. / comments
Test and production DBs are currently on premise, but deployment will only require the same deployment agent as we run for our web/windows service deployments.We are using the hosted build service ...
Sam told me what a stub was and I already understand that. What I was asking for was practical advice on how to achieve this in an Azure Devops hosted build. Would I just have a script that ran in the build to create the stub database? I can't put it in the pre/post deployment scripts in the project because this only needs to happen in the hosted build process, not any other time. Has anyone done this before? Do you have any examples you can share? / comments
Sam told me what a stub was and I already understand that. What I was asking for was practical advice on how to achieve this in an Azure Devops hosted build. Would I just have a script that ran i...
SamTouray said:
The creation of the stub is a manual one off task. There is no need to re-create the stub for each build as it won't change.
Except this is an Azure Devops hosted build. As I understand it the VM is freshly created for each job and then discarded. / comments
SamTouray said:
The creation of the stub is a manual one off task. There is no need to re-create the stub for each build as it won't change.
Except this is an Azure Devops hosted build. As I...
SQL Change Automation / comments
SQL Change Automation
Ok, we definitely don't want to merge the databases back together. The whole reason to move the archive tables out of the primary db was to keep the backup sizes sensible in case we need to restore them. Do you have any samples or information around creating a fake for validation purposes? I'm really new to this and would love some help. Cheers. / comments
Ok, we definitely don't want to merge the databases back together. The whole reason to move the archive tables out of the primary db was to keep the backup sizes sensible in case we need to restore...