Comments
Sort by recent activity
Hi DaveRomig Thank you for reaching out on the Redgate forums regarding your SQL Search concerns with SSMS22.3.2 I can confirm that I have these exact versions of SSMS & SQL Search on my own machine currently, and it is running as expected. A partial or interrupted installation is possibly causing the conflict you're finding between VS & SSMS. Try a clean reinstall:
Uninstall SQL Search via Windows Add or Remove Programs
Delete any residual files from %AppData%\Red Gate\SQL Search
Reboot (optional)
Reinstall using the latest installer from https://download.red-gate.com/checkforupdates/SQLSearch/SQLSearch_3.9.6.6522.exe
Launch SSMS and verify if SQL Search is now working for you
[image] / comments
Official comment
Hi DaveRomig Thank you for reaching out on the Redgate forums regarding your SQL Search concerns with SSMS22.3.2I can confirm that I have these exact versions of SSMS & SQL Search on my own machin...
Hi David W Thank you for reaching out on the Redgate forums regarding your Data Compare login error. It may be worth checking whether you have a SID mismatch on the cloned database. When DbaTools clones a DB, the internal user mappings may not carry over cleanly, which can leave the service account as an orphaned user — even if db_owner was granted. Run this to check: USE [DBATestPRDBld]; EXEC sp_change_users_login 'Report'; If the service account shows up, try re-mapping it: ALTER USER [svc.account] WITH LOGIN = [DomainName\svc.account]; A couple of other things to confirm while you're investigating:
/ad2 flag - make sure it's paired correctly with /s2 , /db2 , and your auth parameters
Azure SQL vs. SQL Server VM. If this is Azure SQL (PaaS), Windows/AD auth may not behave as expected and could need a different approach
/ comments
Official comment
Hi David W Thank you for reaching out on the Redgate forums regarding your Data Compare login error.It may be worth checking whether you have a SID mismatch on the cloned database. When DbaTools cl...
Thanks for testing and reporting back, apologies the initial response wasn't clear on this. The sqlMigrationSuffixes setting only applies to the migrations folder, not the schema model. The schema model expects .sql files only and this isn't currently configurable, which is why non-sql files types weren't being picked up. On reflection, it does seem that your prefix-based naming approach is the right workaround here. It's also worth noting that Flyway Desktop automatically organises schema model objects into subfolders by type (procedures/ , triggers/ , etc.), so the folder structure itself provides the object-type context even with a uniform .sql extension. If you'd like to see configurable extensions supported in the schema model, you're welcome to raise or upvote it on our Flyway UserVoice portal: http://redgate.uservoice.com/forums/949477-flyway UserVoice is our feature request site run by our product managers and development teams to help shape the features and functionality of all of our tools, including Flyway. / comments
Thanks for testing and reporting back, apologies the initial response wasn't clear on this.The sqlMigrationSuffixes setting only applies to the migrations folder, not the schema model. The schema m...