Comments
Sort by recent activity
Hello Todd, Thank you for your query. Given your situation I'll give two answers. Official As you likely know, good practice says you should never make changes directly in production and the whys and wherefores of such have been written about exhaustively. But as reality is rarely so neat, please my next paragraph for a compromise. Yes there is an overhead, depending on your actual needs and what options you select, resources available and system load, that could range anywhere from negligible to noticeable. Given it's going to be a live server, your considerations of using the shared model vs dedicated model and their subsequent ramifications also become more involved. That's before you've got to merge conflict resolution. Practical compromise In your scenario I'd Source Control my development environment as that's the principle purpose of source control (opposed to version control) and will give your devs the flexibility to work independently as intended. Then, where the need arises to make a change in production, you can do so and then use the Comparison tools in the toolbelt to deploy those changes back to the dev instance. This gives the best of both worlds along with consistency. Lastly, should you wish to grow out your deployment in future to a full CI/CD pipeline, you'll already be ready to do so rather than having to re-engineer it. Further general reading The 'environments' section of this might be useful to you, but it all applies. https://www.red-gate.com/simple-talk/databases/sql-server/learn/change-management-and-source-control/ Kind regards, Peter Redgate Product Support / comments
Hello Todd,Thank you for your query. Given your situation I'll give two answers.OfficialAs you likely know, good practice says you should never make changes directly in production and the whys and ...
Hello Tom, Since you mentioned partitioning, are you utilising a clustered index, potentially moving the clustered index to a new filegroup? As for expected behaviour, we'd need a fair bit more information to determine that. I'd be happy to open a support ticket for you if you'd like to pursue that. Kind regards, Peter Redgate Product Support / comments
Hello Tom,Since you mentioned partitioning, are you utilising a clustered index, potentially moving the clustered index to a new filegroup?As for expected behaviour, we'd need a fair bit more infor...
Hello Jassim Please can you try targeting the executable of the office application that's hosting your addin? E.G "winword.exe" rather than your add-in DLL When you try and start profiling, ANTS Profiler may warn you that you haven't selected a .NET executable, but accept this warning and carry on anyway. As the application starts up, watch the status bar in ANTS Profiler - it should change from "Waiting for connection..." to "Profiling performance of...". Thanks and kind regards, Peter Redgate Support / comments
Hello JassimPlease can you try targeting the executable of the office application that's hosting your addin?E.G "winword.exe" rather than your add-in DLLWhen you try and start profiling, ANTS Profi...
Hello Louis, Thank you for your query. For your particularly use case, specifically as it's a predictable scenario, my first thought would be creating a post deployment script to check and then restore the filestream property after the migration has run. Post deployment scripts Do you think that could work for you? Regarding it being a selectable ignore property, please could you raise the matter on our User Voice forum? This enables the developers to see community demand for functionality and aids the selection process. User Voice Thank you and kind regards, Peter Redgate Support / comments
Hello Louis,Thank you for your query. For your particularly use case, specifically as it's a predictable scenario, my first thought would be creating a post deployment script to check and then rest...
Nothing to apologise for, thank you for your query Stephen, The behaviour you've described is intended for programmable objects, but there are a few different ways to handle this. From your description it sounds like the following would be the most useful to you. I've also included the associated documentation in case there's additional options that would suit your use case better. ScriptInMigrations - This effectively disables the programmable object feature and scripts all programmable object types out in migration scripts, as with any other object type. Note that if you have already generated programmable objects before selecting this setting, these objects will continue to be deployed. If this is not desirable, delete the programmable objects folder. Regarding the timeout you've experienced, we don't anticipate it being related to programmable objects, or in fact any conflict, which would typically return an error relating to the incompatibility rather than just hanging. Since you mentioned a baseline, just to clarify; If V1.0.0 is a baseline script it should not be deployed to a non-empty database, except if the _MigrationLog table exists and does not have a row stating that the Baseline has been deployed. This scenario is fairly improbable and most likely to occur through manual manipulation, but included for sake of thoroughness. Kind regards, Peter / comments
Nothing to apologise for, thank you for your query Stephen,The behaviour you've described is intended for programmable objects, but there are a few different ways to handle this. From your descript...
Hello JAlessi, Thank you for your query, as it's a parser fault we'll need to examine the code in question. I will raise a support ticket for you to securely upload an example; if the resolution is useful to the community I'll add that here at the end. Kind regards, Peter / comments
Hello JAlessi,Thank you for your query, as it's a parser fault we'll need to examine the code in question.I will raise a support ticket for you to securely upload an example; if the resolution is u...
Thank you for helping us identify the parser issue, the patch should be released shortly. As an interim solution, please use single quotes on the origin reference for bulk insert statements. Kind regards, Peter / comments
Thank you for helping us identify the parser issue, the patch should be released shortly.As an interim solution, please use single quotes on the origin reference for bulk insert statements.Kind reg...
This fix is now available in SQL Source Control. Kind regards, Peter / comments
This fix is now available in SQL Source Control.Kind regards,Peter
Hello @pramodcrowe Given the tag you've placed on this query, please can you confirm if your implementation is a SQL Change Automation project with a SQL Source Control source? If so the implementation of post deployment scripts changes somewhat and you will need to factor in these considerations and the products will only reference a single script. https://documentation.red-gate.com/soc/common-tasks/working-with-pre-post-deployment-scripts Here's a overview of the interaction between the two products for context. https://documentation.red-gate.com/sca/developing-databases/concepts/development-source Kind regards, Peter / comments
Hello @pramodcrowe Given the tag you've placed on this query, please can you confirm if your implementation is a SQL Change Automation project with a SQL Source Control source?If so the implementat...
Hello, Sorry for not seeing this initially, it is a very old thread. Yes .Net 8 support has been released and we're starting work on .Net 9 straight way. There was a drop in our cadence of releases while we addressed some internal architecture, which we've now completed, thank you for bearing with us. We'll keep you in the loop as things progress. The closed beta for .Net 8 support was quite successful, so we may do the same for 9. If we did, would the thread participants be interested? / comments
Hello,Sorry for not seeing this initially, it is a very old thread.Yes .Net 8 support has been released and we're starting work on .Net 9 straight way. There was a drop in our cadence of releases w...