Comments
Sort by recent activity
I also just confirmed I have the same behavior with filtering out Partition Function in another database I'm working on. / comments
I also just confirmed I have the same behavior with filtering out Partition Function in another database I'm working on.
And, just let me say, how awesome* you guys are.
/IgnoreDataCompression
totally works and solves my issue.
*Because this means of course that you are guilty only of fully implementing a feature and simply not documenting it. You guys would fit in great at our place. [image] / comments
And, just let me say, how awesome* you guys are.
/IgnoreDataCompression
totally works and solves my issue.
*Because this means of course that you are guilty only of fully implementing a feature and...
Done.
Voted up and commented on this item http://redgate.uservoice.com/forums/390 ... bject-inst / comments
Done.
Voted up and commented on this itemhttp://redgate.uservoice.com/forums/390 ... bject-inst
so here's my latest (last?) attempt:
(1) Make hot fix in production
(2) Commit through SSC, push change to prod mercurial repository
(3) Terminal Service into shared DEV SQL Server
(4) pull prod repository into dev and merge changes
(5) Go into SSMS where SSC is setup as a dedicated link to mercurial
(6) Do a get latest and
(a) hopefully just push the new hotfix into dev because nobody has changed the objects in the hotfix in DEV since the last release
(b) manually merge the changes in if someone has modified the objects in the hotfix since the last release
(7) commit from SSC, push to hg dev
This is still awfully manual, especially if step 6 (b) is necessary, but it does establish a process and it does work.
What would be GREAT is if SSC included some basic merge functionality!
What's the chance of that anytime soon? [image] / comments
so here's my latest (last?) attempt:
(1) Make hot fix in production
(2) Commit through SSC, push change to prod mercurial repository
(3) Terminal Service into shared DEV SQL Server
(4) pull prod re...
The problem with 2) is that we may already be working in DEV on future changes to the objects we are deploying to PROD. So auto deploying sp_ReadCustomers from Wednesday's deployment to PROD may mean I overwrite Tuesday's changes to sp_ReadCustomers in the shared DB environment. / comments
The problem with 2) is that we may already be working in DEV on future changes to the objects we are deploying to PROD. So auto deploying sp_ReadCustomers from Wednesday's deployment to PROD may me...
I actually just finished a little project last night to be able to generate those argument XML files based on a set of tables (We currently have 16 databases on 4 servers under source control)
I was only planning on generating them when we had an overall build or other environment changes, but now that you mention it, I supposed I could modify that process to read the names of the files in the data directory and translate that to an include element.
Very good. Thanks for the idea. / comments
I actually just finished a little project last night to be able to generate those argument XML files based on a set of tables (We currently have 16 databases on 4 servers under source control)
I wa...
Implemented your idea and we're back to normal run times. Thanks. / comments
Implemented your idea and we're back to normal run times. Thanks.
Great, thanks. I figured that's what was happening. I appreciate you checking to see if the behavior can be changed.
Any other suggestions on what we might do in the interim?
I assume migration scripts would be an option, but we're using mercurial so they're not available to us yet (ETA?)
Our current workaround is just to have each developer understand that we can't currently generate rollbacks for data and they are responsible to "know" when they're pushing data between environments and make them responsible to write a rollback script for the final release and attach it to the "release ticket" with the other autogenerated scripts. / comments
Great, thanks. I figured that's what was happening. I appreciate you checking to see if the behavior can be changed.
Any other suggestions on what we might do in the interim?
I assume migration s...
Definitely would be interested in trying out the fix and please do put me on the Early Access Build list. Everyone is very happy with our new process and we're just trying to wring the inefficiencies in our process out.
Thanks for the quick reply! / comments
Definitely would be interested in trying out the fix and please do put me on the Early Access Build list. Everyone is very happy with our new process and we're just trying to wring the inefficienc...
I have setup based on Troy's article and I can confirm that it does just sync the data under source control. / comments
I have setup based on Troy's article and I can confirm that it does just sync the data under source control.