User profile for Chris Auckland

Thanks for your post. Unfortunately SQL Prompt 3.6 does not support using 'run as' to open SSMS with a different account. This is a known issue and is currently scheduled to be fixed in version 3.8. For your reference the bug tracking number for this case is SP-799. However, there is a workaround that you may wish to try. First log into Windows with the account you were previously using with 'Run as' and open SSMS, the SQL Prompt add-in should load correctly. If you then log out and log back in with your usual account, when you open SSMS with 'Run as' the add-in should load this time. I hope this helps. p.s. SQL Prompt 3.6 is the current realese, you can upgrade to this using the 'check for updates' function from the SQL Prompt menu in SSMS. / comments

Thanks for your post. Unfortunately SQL Prompt 3.6 does not support using 'run as' to open SSMS with a different account. This is a known issue and is currently scheduled to be fixed in version 3.8...

0 votes

Thanks for your post. Currently the only way to select the server using the SQL Dependency Tracker viewer is to choose the server from the list. I think your suggestion would be a useful addition to the tool so I have logged a request for our developers to include the feature in a future version. For your reference the feature was logged under the code DT-450. I have associated your details with the report, so I can update you once the log has been reviewed. I will let you know as soon as I hear anything. / comments

Thanks for your post. Currently the only way to select the server using the SQL Dependency Tracker viewer is to choose the server from the list. I think your suggestion would be a useful addition t...

0 votes

Thanks for your post. I've just tested this myself and it does appear that the excluded objects in the comparison project are not getting honoured when run from the command line. I have now logged a bug describing this fault. For your reference the bug code is SC-3653, hopefully the fix will be included in the next version. I have associated your details with the bug, so I will be able to update you when we have some more information. As a temporary workaround, you can explicitly use the /exclude switch from the command line, you will be able to exclude the objects you need to. For example, you can run the following command to exclude the Table1 table from the comparison:: SQLCompare /pr:<SQL Compare Project> /exclude:Table:\[Table1\] You can exclude multiple objects by separating the object with the | character, e.g. /exclude:Table:\[Table1\]^|\[Table2\]^|\[Table3] I hope this is helpful / comments

Thanks for your post. I've just tested this myself and it does appear that the excluded objects in the comparison project are not getting honoured when run from the command line. I have now logged ...

0 votes

Thanks for your post. There isn't any way to configure SQL Compare to generate the script without setting ARITHABORT ON. This is because it is used to enables us to roll back if a divide-by-zero error occurs. As you have discovered, if you do not wish to use the option, you can remove it from the script after it has been generated. Incidentally, what was the exact error you received when you ran the script with ARITHABORT ON? Here is some reference material on ARITHABORT: http://technet.microsoft.com/en-us/libr ... 90306.aspx / comments

Thanks for your post. There isn't any way to configure SQL Compare to generate the script without setting ARITHABORT ON. This is because it is used to enables us to roll back if a divide-by-zero e...

0 votes

Thanks for your post. Unfortunately with the current release it is not possible to treat these queries as identical. SQL Compare is not setup to ignore the database names when comparing cross database queries. I agree that this would be a useful addition to SQL Compare, so I have logged a feature request with the developers. For your reference the code it was logged under was: SC-3585. I will let you know the status after it has been reviewed. / comments

Thanks for your post. Unfortunately with the current release it is not possible to treat these queries as identical. SQL Compare is not setup to ignore the database names when comparing cross datab...

0 votes

Thanks for your post. There is no problem if you want to take ad-hoc full backups for a database you are using for log shipping. This is because taking a full backup does not truncate the transaction log, and therefore does not affect what is contained in the transaction log backups. The only thing to watch out for is that you do not take this full backup at the same time that a t-log backup is scheduled. If the tasks clash they will cause one of the jobs to fail. You must make sure that the full backup occurs after the t-log backup has completed, and the full backup must have completed before next t-log backup runs. I hope this answers your question. / comments

Thanks for your post. There is no problem if you want to take ad-hoc full backups for a database you are using for log shipping. This is because taking a full backup does not truncate the transacti...

0 votes

Thanks for your post. Due to the nature of the simply recovery model, it is not possible to take a transaction log backup while the database is in simple recovery mode. For reference: SQL 2000: http://msdn2.microsoft.com/en-us/librar ... 551(SQL.80).aspx SQL 2005: http://msdn2.microsoft.com/en-us/librar ... 0.aspx?s=1 This is why the backup failed. However, it is quite curious that the backup works most of the time time, but fails with this error on occasion. I would suspect that you may have a maintenance plan or other job that changes the recovery model of certain databases to SIMPLE for whatever reason. After this occurs the t-log backup jobs for those databases will fail. Check the jobs that you have running on that server, they should hopefully explain why this is happening. Please note that you will need to run a full backup to switch to full recovery mode after you have made the change through EM or SSMS. Let me know what you find. / comments

Thanks for your post. Due to the nature of the simply recovery model, it is not possible to take a transaction log backup while the database is in simple recovery mode. For reference: SQL 2000: htt...

0 votes

Thanks for your post. As you have discovered, this is not possible with the current version of SQL Compare. I have logged the suggestion as feature request for a future version, and will update you once the feature request has been reviewed by the developers. For your reference the feature was logged under the code SC-3545 / comments

Thanks for your post. As you have discovered, this is not possible with the current version of SQL Compare. I have logged the suggestion as feature request for a future version, and will update you...

0 votes

Thanks for your post. It will be possible to log ship from SQL 2000 to SQL 2005, as it is possible to restore SQL 2000 transaction logs to a SQL 2005 database. However, it is probably important to note that if you need to bring the SQL 2005 database online in a disaster recovery situation, then once the original SQL 2000 server is back online, you will not be able to restore the standby SQL 2005 database on the SQL 2000 server. This is because even though the transaction logs are from a SQL 2000 database, once they are restored to SQL 2005 it will become a SQL 2005 database, and you are unable to restore a SQL 2005 database on a SQL 2000 server. The different versions of SQL Server do not really make a difference to the way we implement log shipping. All you really need is the ability to perform transaction logs backups, and the presence of the SQL Agent to schedule the job. All full versions of SQL Server have this facility, it is only SQL Express that falls short because it does not have the SQL Agent. I hope this answers your question. Let me know if you need any more information. / comments

Thanks for your post. It will be possible to log ship from SQL 2000 to SQL 2005, as it is possible to restore SQL 2000 transaction logs to a SQL 2005 database. However, it is probably important to ...

0 votes

Thanks for your post. The easiest way to sync multiple databases programmatically will be to use the SQL Data Compare 6 command line interface. You can then sequentially call a project file for each of the comparisons you need to perform. e.g. SQLDataCompare.exe project:"ProjectFile1.sdc" /sync SQLDataCompare.exe project:"ProjectFile2.sdc" /sync SQLDataCompare.exe project:"ProjectFile3.sdc" /sync There is more information on using the command line interface in the helpfile: http://help.red-gate.com/help/SQLDataCo ... dLine.html If you have a single project file already configured and all you need to change is the server or database used in the connection, I think the simplest way to do this would be to make a copy of the project file, and then edit the file using a text editor. When you open a .sdc file in a text editor you can edit the project file xml and change the database and server that you connect to, or from. When you save the file you will be able to call it from the command line and perform the identical comparison but to/from a different database. I hope this answers your question. / comments

Thanks for your post. The easiest way to sync multiple databases programmatically will be to use the SQL Data Compare 6 command line interface. You can then sequentially call a project file for eac...

0 votes

How can we help you today?

Chris Auckland

Comments