Comments
Sort by recent activity
David, many thanks! / comments
David, many thanks!
I've inherited a lot of really poorly designed databases (which is why I went with your tool as opposed to a baked-in HA solution for getting from point A to point [image] . The problem I have is that most of the databases are over 650GB in size, and not all of the tables in these databases have a primary key (so using a WHERE clause for the migrations of those tables is pretty much out), plus in my test where I could use a WHERE clause - it didn't buy me that much in cutting down the deployment time. I have had better results with simply using the IMPORT/EXPORT Wizard in SQL for WHERE clause migrations, so I split my migrations between your tool and that.
The Fast Deployment solution was a good way for me to run the process without having to wait for the Compare to complete, but now that it is gone from this new release - I've uninstalled it, and gone back to 11.6.x.x.
I have a massive migration coming up in the next month, and no time to waste on waiting for you guys to put this back in. As for the timestamp that I have asked for repeatedly for the Fast Deployment option, it would be nice to have (so you can see how long a migration takes without having to babysit the whole thing), but even with the request being up in your forum for new features - there was no traction on getting it added. I realize there are log files I can look at in the local profile, but they usually only show when things started - not when they ended. Timestamp feature request https://redgate.uservoice.com/forums/14 ... the-fast-d / comments
I've inherited a lot of really poorly designed databases (which is why I went with your tool as opposed to a baked-in HA solution for getting from point A to point . The problem I have is that mos...
And you base your end user usage stats on what? That is a major part of the deployments I do (so I don't have to baby sit them), and since the request for putting a timestamp on to the deployment window apparently never made it to being released either, it was the only way to migrate my larger databases (without having to physically be there to wait for the never ending compare process to complete).
I won't be using this new version then (and if all future versions of the same, we'll probably end up dropping the product all together).
Thanks a lot for making the migrations of larger database even more cumbersome.
:roll: / comments
And you base your end user usage stats on what? That is a major part of the deployments I do (so I don't have to baby sit them), and since the request for putting a timestamp on to the deployment ...
Check the task manager both before and after you start your tasks, and pay close attention to how many instances of svchost.exe you see (and especially what resources each is taking).
I don't know what version of Windows / Windows Server you are running, but I would start troubleshooting there. / comments
Check the task manager both before and after you start your tasks, and pay close attention to how many instances of svchost.exe you see (and especially what resources each is taking).
I don't know ...
Eddie, thank you! I will post something over there now. / comments
Eddie, thank you! I will post something over there now.
Strange question perhaps, but much needed information. Glad to know that the connection to the source could be dead, and the process will not be killed (once it is at the point of generating the script).
Also - I have asked in the past for a feature to be installed in your Fast Deploy process, which would allow for a timestamp to mark the start and finish of the migration. Maybe that is something you guys could consider implementing in a future update to the product? For those of us who are at the mercy of waiting to see when it completes - we very rarely have the time to sit back, and do such babysitting (and knowing how long a migration takes is key to new system deployments - I doubt I am alone on that). I suppose I can always look at the properties of my database file (to see when it was last modified), but it would just be nice to know from your tool (just in case someone or something else does something to the file before I can get to it - I don't have to guess).
The dropping of the connection is not something I can do anything about, but knowing that so long as it has gotten to the point of Generating the script has the process in the clear, is good to know.
Thank you / comments
Strange question perhaps, but much needed information. Glad to know that the connection to the source could be dead, and the process will not be killed (once it is at the point of generating the s...
I should also mention that I am not running the SQL Data Compare tool on my target database server. The app is on a 3rd server (which is where we do all of our staged syncing from), and I already know about the 3 to 4 times the actually database size for that system to have. / comments
I should also mention that I am not running the SQL Data Compare tool on my target database server. The app is on a 3rd server (which is where we do all of our staged syncing from), and I already ...
So - the job eventually failed, but did not fail because of a lack of disk space. It did give the following error though: Error: Synchronization of 'MySourceServer.MySourceDatabase' and 'MyTargerServer.MyTargetDatabase' failed: An attempt was made to move the file pointer before the beginning of the file.
Have looked and searched out here, but am not finding reference to this error. Need support on this please, thanks. / comments
So - the job eventually failed, but did not fail because of a lack of disk space. It did give the following error though:Error: Synchronization of 'MySourceServer.MySourceDatabase' and 'MyTargerSe...
Hello Eddie, and thank you for the response.
Unfortunately - I am needing to automate this process (because of the type of database in question - it makes multiple schema changes daily on the front end - it's a database for a API monitoring tool).
It looks like you are referencing a .txt file from the example you gave. Is this the diff between the two that you then have the Task Schedule pick up to process the diff with? If so - I am guessing there must be a way to automate the diff to text?
Thanks again / comments
Hello Eddie, and thank you for the response.
Unfortunately - I am needing to automate this process (because of the type of database in question - it makes multiple schema changes daily on the front...
The scripts is too large to open up in SSMS. Isn't there a way to add to your command line option a time stamp for the beginning and ending of the process? I am working on a major migration of databases right now, and the process is very slow. I need to be able to give a definitive answer as to how long each database is going to take (to determine an appropriate downtime window for the maintenance), but I am beginning to be challenged by my team as to why restoring the old databases would not be a better solution (and there are multiple reasons for why that is not viable that I will not go into - be it safe to say that this is why I am looking at SQL compare and SQL data compare). I've tried both backup to database (extremely slow) and database to database (very slow as well). If I could at least get an idea on the length of time it is going to take to do each database, it would help me in justifying the tools, but right now it's taking so long for a few of them, that I cannot just sit around and wait for them to complete. I am using the Fast Deploy option so I don't wind up with 2 lengthy compares. / comments
The scripts is too large to open up in SSMS. Isn't there a way to add to your command line option a time stamp for the beginning and ending of the process? I am working on a major migration of da...