Comments
Sort by recent activity
By default DLM Automation will try to create a database on localDB on the Bamboo agent (whether this is an on prem or cloud agent). https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/sql-server-2016-express-localdb
If local DB is not installed on your build agent you should provide details for your own SQL instance where DLM Automation will build the database. / comments
By default DLM Automation will try to create a database on localDB on the Bamboo agent (whether this is an on prem or cloud agent).https://docs.microsoft.com/en-us/sql/database-engine/configure-win...
I'm afraid there isn't. Not without unlinking and relinking anyway.
Can you tell me a little bit more about your custom objects? Are these for different versions of production (e.g. for different customers) or for dev/test databases? Are we talking about schema or static data differences? What sorts of objects? Tables, sprocs etc? Do you have handy naming conventions?
There are clever things you can do with filters and post deploy scripts etc. For example: https://www.red-gate.com/hub/product-learning/sql-compare/how-to-build-multiple-database-versions-from-the-same-source-using-sql-compare-filters / comments
I'm afraid there isn't. Not without unlinking and relinking anyway.
Can you tell me a little bit more about your custom objects? Are these for different versions of production (e.g. for different c...
I'm afraid not: https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/1267757-allow-me-to-specify-a-subset-of-columns-for-static / comments
I'm afraid not:https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/1267757-allow-me-to-specify-a-subset-of-columns-for-static
I'm trying to think of a good way to do this but can't think of anything better than move the static data and "not static data" into different tables.
Is there any reason why you can't do that? (Other than the fact that this sounds like a complicated data migration). / comments
I'm trying to think of a good way to do this but can't think of anything better than move the static data and "not static data" into different tables.
Is there any reason why you can't do that? (Ot...
Thank you Xanthe, and everyone who voted for me.
And thanks Redgate for creating awesome software that makes my life easier. :-) / comments
Thank you Xanthe, and everyone who voted for me.
And thanks Redgate for creating awesome software that makes my life easier. :-)
Thank you Geovanny. That means a lot. :-)
I've taken a look through the directory and there are so many people I want to nominate! I've now written and deleted this post many times, nominating different people every time. (Sorry to Cathrine Wilhelmsen, Bob Walker, Rob Sewell, Troy Hunt and the John Morehouse/Chris Yates double act. You were all a close second.) This just goes to show how many folks in this program contribute so much.
I've settled on Alessandro Alpi. Earlier this year I was with a customer who had lot's of developers and lots of databases with lots of cross DB dependencies. They wanted to move to the dedicated model but each time they respawned their local dev server there was the painful task of re-linking all the databases in SQL Source Control. This was a slow process, exasperated because of the size and complexity of some of the databases.
We took Alessandro's PowerShell script to auto-link the databases, tweaked it a bit to make it work in Git (it was designed for TFS) and hey presto - we had a magic "link all my databases to source control" button. Sweet!
Thanks Ale, you helped us out. You made a specific contribution that was enormously valuable and useable for me and one of my customers. / comments
Thank you Geovanny. That means a lot. :-)
I've taken a look through the directory and there are so many people I want to nominate! I've now written and deleted this post many times, nominating diff...
Thanks Geovanny, means a lot.
I've been struggling with this one because there are so many folks in the directory I want to nominate.
I've decided to nominate Alessandro Alpi because he made a specific contribution that I was able to use and take value from.
Earlier this year I was with a customer who wanted to move to the dedicated model in SQL Source Control. They had lots of developers and lots of databases across two instances and many dependencies between the databases.
We established a process to automate the provisioning of a local dev server with both instances and all the databases (with appropriate test data) on the dev laptops but the process of linking to source control was slow, manual and painful.
We took Alessandro's PowerShell script which automates the linking process in SQL Source Control, tweaked it to work with Git (it was designed for TFS) and hey presto - we had a magic "link all my databases" button. Sweet!
Ale, thank you. You saved us all a bunch of work. And for that reason I nominate you as FoRG of the year. :-) / comments
Thanks Geovanny, means a lot.
I've been struggling with this one because there are so many folks in the directory I want to nominate.
I've decided to nominate Alessandro Alpi because he made a spec...
I have been asked about main issues ppl have with ReadyRoll:
- less intuitive (shadow DB, how to do the traditional commit, get latest, apply to my local DB, the dpeloyment package has various formats, which one should i chose? how do I automate that?)
- I got some error that I don't understand, what now?
- Migrations approach is fundamentally better for deployment but harder for dev
- Whoh, what's this Visual Studio thing? I'm a SQL guy, I don't understand VS projects. I just like plain simple sql scripts in source control
Admitedly, for folks coming from an SSDT background and who want to move to a migrations approach RR may be more intuitive. / comments
I have been asked about main issues ppl have with ReadyRoll:
- less intuitive (shadow DB, how to do the traditional commit, get latest, apply to my local DB, the dpeloyment package has various form...
In my experience, when a bunch of people have trialled SQL Source Control and ReadyRoll side by side, the majority like SQL Source Control better. They like it because:
- It's simpler (RR can feel more complicated and is often more of a headache to set up)
- SSMS integration
- Model approach is easier wrt branching and conflict resolution etc
Of course, the pain occurs at deployment time when the SQL compare generated script doesn't work, but the HTML diff report generated by DLM Automation is a wow moment that a lot of folks like. And frankly, the easy solution that solves 80% of deploy issues pretty quickly aligns well with a lean approach to improving dev processes. Get something that mostly works pretty quick and iterate from there - as long as you have a good feedback mechanism for when the process doesn't work and you need to intervene.
My view is that eventually, when ppl get to full devops, ReadyRoll is probably a better solution and the html report/any approval gates become less relevant/actual blockers on the process - but that's only possible once people have built up confident in tooling and, you know, thought about testing?
I do see SQL Source Control and DLM Automation as the natural first step for a lot of customers and my main Q is:
Will the existing SQL Source Control and DLM Automation story still exist? Is it going away? Do I need to stop recommending it? / comments
In my experience, when a bunch of people have trialled SQL Source Control and ReadyRoll side by side, the majority like SQL Source Control better. They like it because:
- It's simpler (RR can feel ...
Comment - in summary, most of my customers are probably currently at persona 2/3. Some aspire to be persona 4 but they aren't ready yet. / comments
Comment - in summary, most of my customers are probably currently at persona 2/3. Some aspire to be persona 4 but they aren't ready yet.