User profile for howarthcd

Hi @Alex B, I think I've sussed out what's going on. If the schema name in which the table is being created has the same name as a database attached to the instance of SQL Server, then the error occurs. You should be able to replicate the behaviour if you try this on a SQL Server instance: USE master GO CREATE DATABASE Logging GO ...then in a new SSMS query window change context to the new Logging database then refresh the SQL Prompt cache. Then attempt to add semicolons to the following in ANY database on the SQL Server instance (not just the one newly created): CREATE TABLE [Logging].[LogEntries] ( [LogEntryId] INT IDENTITY (1, 1) NOT NULL, CONSTRAINT [PK_LogEntries] PRIMARY KEY CLUSTERED ([LogEntryId] ASC) WITH (FILLFACTOR = 90) ) GO You should then experience the error. It so happens that the database in which I am trying to create the above table is also named 'Logging', I didn't think that this was relevant at first but it now seems that it might be. Thanks Chris / comments

Hi @Alex B, I think I've sussed out what's going on.If the schema name in which the table is being created has the same name as a database attached to the instance of SQL Server, then the error occ...

0 votes

Assuming that you will never have to restore to a point in time between the completion of Full Backup 1 and Full Backup 2, and that you are sure that Full Backup 2 is integral, then yes you can delete the log backups. I'd recommend keeping them for at least 3 days 'just in case', but obviously the retention policy is dependent on your requirements. Chris / comments

Assuming that you will never have to restore to a point in time between the completion of Full Backup 1 and Full Backup 2, and that you are sure that Full Backup 2 is integral, then yes you can del...

0 votes

Brilliant, thanks - seems to be working fine. Thanks again, Chris / comments

Brilliant, thanks - seems to be working fine.Thanks again,Chris

0 votes

DanC said: Hi @howarthcd I've managed to reproduce this, it still allows you to run the comparison in 14.2 although it shows an error. I've done a bug report for this and will keep you posted! Bug report reference SC-10773 Great, thanks for this. I've had to downgrade to v14.1.7.14336 as 14.2 wouldn't work against the database projects, complaining of duplicate definitions in the script files, even though there weren't any duplicates. I did find that if a RedGateDatabaseInfo.xml file is added to the root project folder then the comparison succeeds. / comments

DanC said: Hi @howarthcd I've managed to reproduce this, it still allows you to run the comparison in 14.2 although it shows an error. I've done a bug report for this and will keep you posted...

0 votes

Tianjiao_Li said: Thanks for your patience. I'm pleased to let you know the fix has been released in 14.0.4.13251. Please upgrade at your convenience. Thanks. I've tested this new build and found the problem has been resolved. Thanks for the quick turnaround! Chris / comments

Tianjiao_Li said: Thanks for your patience.I'm pleased to let you know the fix has been released in 14.0.4.13251. Please upgrade at your convenience.Thanks. I've tested this new build and fo...

0 votes

A. SQL Clone / comments

A. SQL Clone

0 votes

I've come up with a workaround which is to append the contents of the StandardError property (which contains the SQL error message) of the SQL Compare process to the output text file. Not ideal but it does the job in my particular situation. / comments

I've come up with a workaround which is to append the contents of the StandardError property (which contains the SQL error message) of the SQL Compare process to the output text file.Not ideal but ...

0 votes

You could do one of the following: 1. Expand the file using the sqb2mtf.exe utility that is installed along with SQL Backup. You should be able to copy this from the server that was used to create the backup file: http://help.red-gate.com/help/SQLBackup5/0/en/Topics/SBU_CommandCONVERT.html#sqb2mtf 2. Install SQL Backup on the server that you are trying to install to and perform the restore within the trial period. Chris / comments

You could do one of the following: 1. Expand the file using the sqb2mtf.exe utility that is installed along with SQL Backup. You should be able to copy this from the server that was used to create ...

0 votes

Hi Nigel Thanks for the update - this does sound promising. We're looking forward to seeing this fixed in a future release. Thanks Chris / comments

Hi Nigel Thanks for the update - this does sound promising. We're looking forward to seeing this fixed in a future release. Thanks Chris

0 votes

I ended up raising this directly with Red-Gate as I was looking for a rapid response, which was as follows: Red-Gate's response: This shouldn't happen as the SQL Backup failure to write the file should be reported back to SQL Server so the whole process is a failure. It may be that the last data block was retrieved from the VDI and then SQL Server truncated the log. The failure could have then happened writing the last few blocks or something similar. The outcome is the same as a corrupted log backup file which is always a risk when backing up straight to a network share. Transferring more data and using Native backup will increase this risk. I am communicating with a developer to see if he can track down an occasion where SQL Backup reports to SQL Server that it is complete before the final data blocks have been written. <Reply sent by me included the failed backup's log file> Red-Gate's response: Thank you for the log file, after discussing this with the development team it seems there is one rare occasion where this can occur. There can be a delay between SQL Backup receiving the data, compressing it and writing it to disk. This delay is caused because the compressed data can not be written to disk before it reaches a specific size, for efficiency and OS requirement issues. SQL Server does not inform SQL Backup that it is sending the last block so when SQL Backup acknowledges it has received that block SQL Server automatically assumes all data has been received/written so SQL Server will perform the truncation. If the last accumulated block of compressed data then then has a problem, it renders the whole backup file incomplete. This is something we are hoping to improve but it may take a lot of work with regards to logic and finding a way to know which block is the last from SQL Server. So it seems that the issue is being caused by an inadequacy inherent in SQL Server's VDI and that most, if not all, 3rd party compression products that rely on the VDI (there is at least one that doesn't) may be open to the same issue. In order to help mitigate the risk I think that we may move to SQL Server 2008's native compression feature when we upgrade. This is unfortunate for Red-Gate as their product is otherwise superb, but we can't afford to risk this happening again. Chris / comments

I ended up raising this directly with Red-Gate as I was looking for a rapid response, which was as follows:Red-Gate's response: This shouldn't happen as the SQL Backup failure to write the file sh...

0 votes

How can we help you today?

howarthcd

Comments