Comments
Sort by recent activity
I'm afraid this is happening on the pre-release build with all encrypted backups version 5.4 or earlier. We've raised this internally so it will be fixed for the final release.
Sorry for the inconvenience! / comments
I'm afraid this is happening on the pre-release build with all encrypted backups version 5.4 or earlier. We've raised this internally so it will be fixed for the final release.
Sorry for the incon...
Hi Dan,
Thanks for raising this with us. I can reproduce this on a test machine here.
Clearly this is a serious issue, and we will want to fix it before the final release. For the time being, I hope you can carry on using the pre-release without too much inconvenience. As you saw, a work-around is to manually remove 5.3 backups from the folders you are backing up to.
Thanks again!
Matt Chandler,
Software tester on SQL Backup / comments
Hi Dan,
Thanks for raising this with us. I can reproduce this on a test machine here.
Clearly this is a serious issue, and we will want to fix it before the final release. For the time being, I h...
Hi Andy,
I can confirm that you will be able to deactivate licenses remotely.
As for centralized license management, I'm afraid there aren't currently any plans to implement this for the next release, but we'll be sure to review this feature for releases in the future.
Many thanks for your feedback, / comments
Hi Andy,
I can confirm that you will be able to deactivate licenses remotely.
As for centralized license management, I'm afraid there aren't currently any plans to implement this for the next relea...
Hi Tim,
If you specify the MAILTO, MAILTO_ONERRORONLY, or MAILTO_ONERROR keywords as part of the restore command SQL Backup uses, then SQL Backup ought to send out an email with the password obfuscated. This should be exactly the same as performing a restore from the GUI.
If you send out an email from SQL Server containing the command string used (for example), then I'm afraid it will necessarily have the password used in plain text.
Thank you for raising this issue. I think its fair to say that this usecase wasn't considered when we first removed the encrypted password in restore commands. Although its unlikely that we will implement a similar feature for the forthcoming release I hope we can do something to help in a future release. As Priya mentioned earlier in this thread, its quite possible that a 'scheduled restore' wizard might be added to SQL Backup in an upcoming version. / comments
Hi Tim,
If you specify the MAILTO, MAILTO_ONERRORONLY, or MAILTO_ONERROR keywords as part of the restore command SQL Backup uses, then SQL Backup ought to send out an email with the password obfusc...
Hi Tim,
I was under the impression that the automated emails sent by SQL Backup for restores obfuscated the password; when I run a restore with a MAILTO command, it shows the password as:
... PASSWORD = 'XXXXXXXXXX', ...
Is this the scenario you were talking about? Or is there a different case we aren't aware of? I'd certainly agree that sending out passwords in clear text would be a serious security issue.
Thanks for the feedback, / comments
Hi Tim,
I was under the impression that the automated emails sent by SQL Backup for restores obfuscated the password; when I run a restore with a MAILTO command, it shows the password as:
... PASSW...
Hi Andrej,
We typically drop foreign key constraints towards the start of a deployment script, to enable the dropping of the keys they reference. In this case however, I think you are correct that the whole table could have been dropped in one operation. / comments
Hi Andrej,
We typically drop foreign key constraints towards the start of a deployment script, to enable the dropping of the keys they reference. In this case however, I think you are correct that...
Hi Jeremy,
I'm afraid it isn't possible to do this in Data Compare at the moment. If this would be a valuable feature to you could I suggest you leave a suggestion on uservoice. We use these requests to help prioritize upcoming work. / comments
Hi Jeremy,
I'm afraid it isn't possible to do this in Data Compare at the moment. If this would be a valuable feature to you could I suggest you leave a suggestion on uservoice. We use these req...
Hi Karthink,
I'm afraid there is no way to manually choose which changes to deploy, although project options (https://documentation.red-gate.com/display/SC12/Setting+project+options) can be used to exclude some differences from deployments. / comments
Hi Karthink,
I'm afraid there is no way to manually choose which changes to deploy, although project options (https://documentation.red-gate.com/display/SC12/Setting+project+options) can be used to...
Hi there,
I'm afraid that SQL Data Compare will not help with this as it only deploys changes through querying and inserting data through SQL Server itself, not disk operations.
I don't believe any Redgate tools will do exactly this but it might be worth checking out Redgate SQL Clone if you are concerned with replicating databases across different environments / comments
Hi there,
I'm afraid that SQL Data Compare will not help with this as it only deploys changes through querying and inserting data through SQL Server itself, not disk operations.
I don't believe any...
Hello,
I'm sorry you have run into this problem. I am afraid we are no longer actively working on v10 of Compare so the only thing I can suggest is to upgrade to a newer version which should not have this issue. / comments
Hello,
I'm sorry you have run into this problem. I am afraid we are no longer actively working on v10 of Compare so the only thing I can suggest is to upgrade to a newer version which should not h...