How can we help you today? How can we help you today?
Jon Kirkwood
Hi Brian  Thank you for reaching out on the Redgate forums with your Flyway extension inquiry.  Yes, this may be supported in Flyway for your requirements.   By default, Flyway scans for .sql file types to read in for migrations. However, you can configure additional suffixes using the flyway.sqlMigrationSuffixes setting, for example: flyway.sqlMigrationSuffixes=.sql,.pkg,.pkb,.prc,.trg Documentation: https://documentation.red-gate.com/flyway/reference/configuration/flyway-namespace/flyway-sql-migration-suffixes-setting   That said, while it’s possible, it does add complexity.  All environments (developers, CI, build agents) would need to use the same configuration, and it moves away from Flyway’s default conventions.   Flyway determines object type from the SQL inside the file (not the extension), which means in most cases, keeping everything as .sql is the simpler and more maintainable approach.   The sqlMigrationSuffixes setting is not maintained through Flyway Desktop. You would need to modify your configuration file directly.  Information on the expected layout of this field can be found on the link provided above.   Hope this helps with your project and filetype naming. / comments Official comment
Hi Brian Thank you for reaching out on the Redgate forums with your Flyway extension inquiry. Yes, this may be supported in Flyway for your requirements. By default, Flyway scans for .sql file type...
0 votes
Hi lilly44  Thank you for reaching out on the Redgate forums regarding your inquiry for script creation & management. I noted you have posted in an Oracle forum so assuming you are using Oracle and possibly a mix of other database types. A good approach is to use a migrations-based workflow; so every database change is captured as a script, versioned, and deployed in a controlled way.   Redgate Flyway is designed specifically for this. It allows you to: • Create versioned migration scripts (for example: V1__create_tables.sql , V2__add_indexes.sql ) • Store scripts in source control (Git, Azure DevOps, etc.) alongside your application code • Automatically track which scripts have been applied using a schema history table • Deploy changes consistently across dev, test, and production environments • Integrate into CI/CD pipelines to reduce manual deployment risk   A typical workflow example might be similar to this: Developer creates a new migration script for the required change Script is committed to source control Flyway runs during build/release and applies any pending migrations Flyway records the change so it won’t run again This ensures changes are traceable, repeatable, and reduces deployment errors.   You can learn more about Flyway here: https://www.red-gate.com/products/flyway/ This page includes additional information on features, supported databases (including Oracle), and the option to download a free trial so you can test it within your own environment and workflows. / comments Official comment
Hi lilly44 Thank you for reaching out on the Redgate forums regarding your inquiry for script creation & management. I noted you have posted in an Oracle forum so assuming you are using Oracle and ...
0 votes
Hi SeannM  Thank you for reaching out on the Redgate forums regarding your DLM Dashboard question.   As you've confirmed, DLM is a retired product so suggestions are made at a risk.   Unfortunately, DLM Dashboard doesn’t provide any supported way to edit or amend an acknowledged comment once it’s been saved.  Those comments are written directly into the Dashboard’s internal data store, which is based on a RavenDB, and there is no UI or API exposed for safely modifying them after the fact.   While it is technically possible to change the data by editing the RavenDB database directly, this is not something we recommend.  It’s complex, undocumented, and carries a real risk of corrupting the Dashboard’s state or audit history; especially since the product has been retired and is no longer maintained.   In practice, the safest options are: Leave the original comment as-is and add a new comment clarifying or correcting the typo Or, if this is for audit or compliance purposes, document the correction externally (for example in your ticketing or change-management system) I know it’s not ideal for small typos, but this approach preserves the integrity of the audit trail and avoids risking the underlying data store. Hope that helps. / comments Official comment
Hi SeannM Thank you for reaching out on the Redgate forums regarding your DLM Dashboard question. As you've confirmed, DLM is a retired product so suggestions are made at a risk.  Unfortunately, DL...
0 votes
Hi Patrick Ortuso  Thank you for reaching out via the Redgate forums regarding your SQL Prompt formatting inquiry.  You could potentially do this using the SQL Prompt bulk-formatter formatter, which lets you apply formatting styles to SQL inside or outside of SSMS before it’s executed.  This is the supported way to format dynamically generated SQL, as there’s no API or T-SQL function to apply SQL Prompt styles directly in memory.    How it could work in your case:  Your process generates the stored procedure SQL Write it out to a .sql file Run the SQL Prompt command-line formatter on that file  Alternatively run the bulk-formatter from within SSMS It rewrites the file using your chosen SQL Prompt style Execute the formatted SQL to create the procedure  Licensing note: The bulk formatting / command-line operations requires either a SQL Toolbelt Essentials or SQL Toolbelt license. It’s not included with standalone SQL Prompt.    Here are some documentation links if you would like to learn more about this: Within SSMS: https://documentation.red-gate.com/sp/features-requiring-a-specific-license/bulk-operations/bulk-operations-in-ssms/bulk-formatting   Via Command-Line: https://documentation.red-gate.com/sp/features-requiring-a-specific-license/bulk-operations/bulk-operations-via-the-command-line  / comments Official comment
Hi Patrick Ortuso Thank you for reaching out via the Redgate forums regarding your SQL Prompt formatting inquiry. You could potentially do this using the SQL Prompt bulk-formatter formatter, which ...
0 votes
Hi huey    Thank you for reaching out on the Redgate forums with your bulk-scripting request. You can absolutely mass-deploy SQL instances into Redgate Monitor without clicking through the UI.   On the Configuration > Example Scripts page of your Monitor installation (https://<your-monitor-server>/Configuration/ExampleScripts ), there’s a full PowerShell example showing how to add: Windows SQL instances Linux SQL instances PostgreSQL Azure SQL / Managed Instance RDS / Aurora Flexible Postgres [image] Once you’ve reviewed the examples, you can add in a loop through your server list; something like this: $servers = @( "ServerA\SQL2019", "ServerB\SQL2017", "ServerC" ) foreach ($name in $servers) { Write-Host "Adding $name..." $instance = New-RedgateMonitorSqlServer ` -FullName $name ` -BaseMonitor $BaseMonitor $instance | Add-RedgateMonitorMonitoredObject } That’s usually the fastest way to bulk-register dozens or hundreds of instances.   If you haven't used the Powershell API before - I would recommend starting here: https://documentation.red-gate.com/monitor14/api-239668740.html to get the necessary info on how to download the Powershell cmdlets from your Monitor instance, generate a token and create your connection to the API to add your instances. / comments Official comment
Hi huey  Thank you for reaching out on the Redgate forums with your bulk-scripting request.You can absolutely mass-deploy SQL instances into Redgate Monitor without clicking through the UI. On the ...
0 votes