Comments
Sort by recent activity
Thanks to you both for that.
You're right, with multiple threads there is interleaved data in the file as backed up by those threads. This is to maximise the speed of the backup, as it avoids the threads waiting on each other in order to write the backup file in a precise sequence.
As an update, re the time taken to check passwords/validate backups performed with multiple threads: we've confirmed similar behaviour under certain conditions in our test suite - we're just isolating exactly what the cause is, and exactly when it happens. I'll get back to you as soon as I know more.
Thanks for your help so far.
All the best,
Dan / comments
Thanks to you both for that.
You're right, with multiple threads there is interleaved data in the file as backed up by those threads. This is to maximise the speed of the backup, as it avoids the t...
Hi Marc,
Thanks, that's useful. We'll try and reproduce it locally and get back to you, hopefully tomorrow.
All the best,
Dan / comments
Hi Marc,
Thanks, that's useful. We'll try and reproduce it locally and get back to you, hopefully tomorrow.
All the best,
Dan
Thanks for your replies.
Can I confirm you're both using SQL Backup 5? Backup 5 should indeed generate one file regardless of the number of threads.
All the best,
Dan / comments
Thanks for your replies.
Can I confirm you're both using SQL Backup 5? Backup 5 should indeed generate one file regardless of the number of threads.
All the best,
Dan
Hello all,
Interesting, I'll take a look at these - can you let me know what other settings you had for those backups, if they're easily to hand. We'll try and reproduce this delay locally and see about investigating why it's happening.
All the best,
Dan
Dan J Archer
Red Gate Software / comments
Hello all,
Interesting, I'll take a look at these - can you let me know what other settings you had for those backups, if they're easily to hand. We'll try and reproduce this delay locally and see ...
Hi Marc,
If you hit Cancel on that "SQL Backup is closing" dialog, it'll restore the GUI's main window so you can carry on working. I know it's not much help, but..;)
All the best,
Dan / comments
Hi Marc,
If you hit Cancel on that "SQL Backup is closing" dialog, it'll restore the GUI's main window so you can carry on working. I know it's not much help, but..;)
All the best,
Dan
Hi there,
If this is a genuine timeout due to a slow or busy server, you may be able to mitigate the situation by changing the default timeouts for that server. If you edit the server's connection properties and go to the second tab, you can change the timeouts there.
Adjusting them down is not necessarily a good plan, as it can lead to failures purely due to low values. But adjusting them up for cases where timeouts are occurring is certainly worth a go.
I hope this helps,
All the best,
Dan
Dan J Archer
Red Gate Software / comments
Hi there,
If this is a genuine timeout due to a slow or busy server, you may be able to mitigate the situation by changing the default timeouts for that server. If you edit the server's connection ...
You're quite right, that option is entirely allowed, but it's one of the ones that the GUI can't edit.
The GUI doesn't attempt to edit jobs that don't conform to a relatively strict syntax. This is primarily to avoid fringe cases where the GUI might think it can successfully edit your job, but could end up losing advanced syntax when saving it back. We figured that preserving the integrity of the job as is is more important than always being able to edit from the GUI.
If there are particular options you'd really like to see in the GUI, feel free to post on here letting us know. The more people tell us, the more leverage we have when it comes to trying to get such features into future release.
Thanks very much,
Dan
Dan J Archer
Red Gate Software / comments
You're quite right, that option is entirely allowed, but it's one of the ones that the GUI can't edit.
The GUI doesn't attempt to edit jobs that don't conform to a relatively strict syntax. This is...
Hi Randy,
There's no hard limit on Dependency Tracker, but as you've noticed some of the layouts perform significantly worse with substantial numbers of objects.
Version 2 has been tested with up to a couple of thousand objects, though not all layouts are performant at this point. On the other hand, 48 hours does seem very excessive. Was the CPU usage for Dependency Tracker still high at that point? I'm not certain, but this could be a bug in our layout algorithms.
I'm not sure if you can send us the data in question, but if so we may be able to try and diagnose the problem.
All the best,
Dan / comments
Hi Randy,
There's no hard limit on Dependency Tracker, but as you've noticed some of the layouts perform significantly worse with substantial numbers of objects.
Version 2 has been tested with up t...
Hi Scotty,
That's a feature I really wanted to see for Dependency Tracker 2.0, but unfortunately didn't make the cut, purely due to time constraints.
It's definitely high on the list of possibles for the next version of Dependency Tracker. It's something I keep looking for when using the app myself [image]
All the best,
Dan / comments
Hi Scotty,
That's a feature I really wanted to see for Dependency Tracker 2.0, but unfortunately didn't make the cut, purely due to time constraints.
It's definitely high on the list of possibles f...
As an aside, all the scripts associated with objects in the project are saved with the project; so you should be able to right-click an object and "Show SQL Script". You can freely e-mail or copy SQL Dependency Tracker projects around and work with them offline, although you do need a licensed or trial version of Dependency Tracker to view them.
All the best,
Dan / comments
As an aside, all the scripts associated with objects in the project are saved with the project; so you should be able to right-click an object and "Show SQL Script". You can freely e-mail or copy S...