Comments
Sort by recent activity
I am having this same issue. I have checked the project options for the user permissions (under ignore) that you mention are not checked, but all I get still are just the generic logins for the users account.
I tried syncing the changes (less the users) but it gives errors (due to the users not being in the database(s) where the objects are attempting to be created).
I'm Running SQL Compare 11.5.0.126. / comments
I am having this same issue. I have checked the project options for the user permissions (under ignore) that you mention are not checked, but all I get still are just the generic logins for the us...
petey wrote:
The SQL Backup Agent service logs in to SQL Server using either Windows authentication or SQL Server authentication.
The default mode is Windows authentication, where the SQL Backup Agent service will log in using the credentials of the service startup user.
To log in using SQL Server authentication, you need to use the sqbsetlogin extended stored procedure e.g. EXEC master..sp_addextendedproc sqbsetlogin, 'xp_sqlbackup.dll'
EXEC master..sqbsetlogin 'sa', 'sapassword'
EXEC master..sp_dropextendedproc sqbsetlogin
This will set up the SQL Backup service to log in using the sa user. To revert back to Windows authentication, run sqbsetlogin with blank values e.g. EXEC master..sqbsetlogin '', ''
Try running sqbsetlogin without any values, in case the SQL Backup Agent service has been set up to use SQL Server authentication. Then try running a backup, after setting up the service startup user to be an account you know has sysadmin rights to SQL Server.
This appears to be the solution to a problem I am having in getting my SQL Backups to run (they keep erroring out saying that they cannot log in with the sa account, and that the password is wrong). This makes sense as I just recently changed the sa password on 2 diiferent servers and instances, and now this won't work - but I really do not want SQL Authentication being used to run the RedGate service/backup with anyway. So - I tried to run the code above to reset it back to Windows Authentication, but all I get is a 'Could not find stored procedure 'master...sqbsetlogin'. If this is a PROC - it's definitely not in the master db of the instance I am trying to fix...Does this work for SQL Backup 7? I am using SQL Backup 7 (7.0.5.1).
Thanks / comments
petey wrote:
The SQL Backup Agent service logs in to SQL Server using either Windows authentication or SQL Server authentication.
The default mode is Windows authentication, where the SQL Backup...
P.S. The result sets of the 4 views and stored space in the 4 tables constitutes about 20 million rows and about 20gb of storage. / comments
P.S. The result sets of the 4 views and stored space in the 4 tables constitutes about 20 million rows and about 20gb of storage.
Nevermind - looks like a UNC is what is needed to get this to work. Question though - I thought you guys addressed being able to back up to mapped drives in a earlier release? Is that not the case? Do you really have to specify a UNC to anything other than the C:DRIVE of a system that has SQL Backup installed? / comments
Nevermind - looks like a UNC is what is needed to get this to work. Question though - I thought you guys addressed being able to back up to mapped drives in a earlier release? Is that not the cas...
I am having this same problem. Can anyone share what the solution was for this? / comments
I am having this same problem. Can anyone share what the solution was for this?
ChrisAVWood wrote:
If you haven't tried the DBCC CHECKDB then it could be the CHECKSUM. It could also be the verify. If your DB is corrupt good luck. You will need Paul Randal's help http://sqlskills.com/blogs/paul/.
hopefully you have the last full backup at hand and if you could run a differential without checksum and verify and you had somewhere else to restore them to you could run the DBCC CHECKDB.
Chris
I'm hoping and praying that I DO NOT have corruption! I have had to go against the grain with every fiber of my being to compromise certain things for this particular database server (because if customer's are complaining about slowness in the environment, then what's the point...).
If it is corrupt, the only silver lining will be the massive push that I have been on for the past month to migrate it over to another server with twice as much RAM (32gb) and the Enterprise Edition of 2005 SQL Server (but the problem has been that they do not want to take the outage to get it done in the simpliest of fashions - just a straight copy of the .mdf and .ldf to get it over to the new box). I guess when they wind up taking an unplanned outage, they might finally move.
Thanks again Chris - I am going to try one more LUN tonight, then see if I cannot run you idea tomorrow as needed. / comments
ChrisAVWood wrote:
If you haven't tried the DBCC CHECKDB then it could be the CHECKSUM. It could also be the verify. If your DB is corrupt good luck. You will need Paul Randal's help http://sqls...
ChrisAVWood wrote:
I am sure that you have already tried this but.
Can you write anything to that drive?
Can you write anything to that drive using the Windows account that SQLBackup is using?
Can you do a log backup or a differential backup rather than a full?
Can you run DBCC Checkdb with PHYSICAL_ONLY on the database in question?
Chris
Hey Chris - no, these are all good questions, and yes to all but the last - I cannot get jobs to execute on this server, not matter what window of opportunity I use. I had to stop all maintenance on the server because of the length of time the jobs were running (even with just the PHYSICAL_ONLY checks on DBCC).
It's been pretty frustrating, and I am getting paranoid about not having any backups of this system (we had another one crash on Monday this week, and had it not been for the backup sets for those databases that I had been keeping, heads would have rolled).
Any other thoughts? / comments
ChrisAVWood wrote:
I am sure that you have already tried this but.
Can you write anything to that drive?
Can you write anything to that drive using the Windows account that SQLBackup is using?
C...
eddie davis wrote:
Hi SQL_ME_RICH
I suspect that you may have a problem with the actual disk drive using the drive letter G:\.
I recommend that you attempt to backup to another disk and see if this action resolves the error.
Many Thanks
Eddie
Hello Eddie - Thank you for the quick response!
The drive in question is a SAN disk, and I probably should have pointed out that it's a NetAPP SAN and the disks have been checked, and have no errors. I have tried multiple LUN's.
This is running SQL Server 2005 Standard Edition 64-bit, which is troublesome enough, but should still work. I am not sure what has caused this to start to fail, and have been investigating everything from the WebApp front end (because of recent deployments all the moving pieces and such) to trying different LUN's to get the thing to backup.
Any other ideas? / comments
eddie davis wrote:
Hi SQL_ME_RICH
I suspect that you may have a problem with the actual disk drive using the drive letter G:\.
I recommend that you attempt to backup to another disk and see if t...
Marianne wrote:
Hi
Many thanks for your feedback. The 'Compressed Size' column in the Backup Properties dialog shows the size of the backup file (whether it was compressed or uncompressed). The column label will be changed in the next version to reflect this.
Cheers,
Marianne
Marianne, thank you for this information, but just out of curiosity then - what is this other file size in the Properties box? Is it just an errant calc? / comments
Marianne wrote:
Hi
Many thanks for your feedback. The 'Compressed Size' column in the Backup Properties dialog shows the size of the backup file (whether it was compressed or uncompressed). The ...
Thx. / comments
Thx.