Settings and activity
18 results found
-
3 votes
James Penman
shared this idea
·
-
1 voteJames Penman
shared this idea
·
-
2 votesJames Penman
shared this idea
·
-
2 votes
An error occurred while saving the comment James Penman
supported this idea
·
-
1 vote
An error occurred while saving the comment James Penman
commented
Any movement on this at all? It seems like quite an oversight and an easy thing to implement considering every other Redgate product generates CLR object scripts just fine.
James Penman
shared this idea
·
-
34 votes
It would be great if you could let us know more about how you’d use a Prompt API / command line version of Prompt.
What problems are you having without it?
How are you getting around those?
How would this make your work better?James Penman
supported this idea
·
-
4 votesJames Penman
shared this idea
·
-
1 voteJames Penman
shared this idea
·
-
19 votesJames Penman
shared this idea
·
-
3 votesJames Penman
shared this idea
·
-
24 votesJames Penman
supported this idea
·
-
636 votes
Hi everyone. I have merged some User Voice items on this topic of “filtered” static data, as there was significant overlap. I want to share our current guidance on handling scenarios where you need to version a subset of the columns and/or rows in the table.
With SQL Source control, the best option at this point is to use a post-deployment script for this purpose.
SQL Source Control introduced pre- and post- scripts in v6.3.
A post-deployment script gives you a good amount of flexibility over exactly which rows or columns of data you want to include in your project. Example post-deployment scripts for static data are here: https://documentation.red-gate.com/soc7/common-tasks/working-with-pre-post-deployment-scripts/static-data
If you make heavy use of Static Data, we have stronger support for this in SQL Change Automation.
SQL Change Automation:
- Supports column filtered static data tables in the SCA plugin in SSMS
- Supports multiple post-deployment scripts, in case there is…
An error occurred while saving the comment James Penman
commented
Absolutely necessary for the reason given. We have lots of tables containing default/global records and user specific content.
James Penman
supported this idea
·
-
100 votesJames Penman
supported this idea
·
-
345 votesJames Penman
supported this idea
·
-
I would like to see history of my search and to be able to re use it fast, right away in search box.
46 votesJames Penman
supported this idea
·
-
16 votesJames Penman
supported this idea
·
-
9 votesJames Penman
supported this idea
·
-
6 votesJames Penman
supported this idea
·
Yes I concur this formatting should be better. The issue is caused by the WITH clause after OPENJSON(), remove the WITH and the OPENJSON() is kept inline with the CROSS APPLY/FROM.