Comments
Sort by recent activity
Hi, thank you for your forum post and sorry that you have encountered a problem.
What is the full version number of SQL Source Control you are using?
A support ticket has been created for you: https://redgatesupport.zendesk.com/agent/tickets/81769
Would you please locate the SQL Source Control log file from the period this error occurred? You will find the log files in this path:
C:Users<user_name>AppDataLocalRed GateLogsSQL Source Control
Please attach a copy of the log file to your support ticket or email support@red-gate.com quoting your call reference #81769, with a copy of the log file attached for us to review.
Many thanks,
Rob / comments
Hi, thank you for your forum post and sorry that you have encountered a problem.
What is the full version number of SQL Source Control you are using?
A support ticket has been created for you: http...
Hi,
SQL Server (and hence also SQL Backup) won't automatically shrink files, even though the space is freed up within the file by a log backup. You can manually shrink your log using DBCC SHRINKFILE (http://msdn.microsoft.com/en-us/library/ms189493.aspx), but you should only do this if it's unlikely to grow again in the future.
In an ideal world, your log file will be large enough that it never normally has to auto-grow between log backups, as that will lead to poor performance. The "Best Practices" section of the MSDN article has some sensible advice.
Hope that helps,
Rob / comments
Hi,
SQL Server (and hence also SQL Backup) won't automatically shrink files, even though the space is freed up within the file by a log backup. You can manually shrink your log using DBCC SHRINKFIL...
As a largely off-topic reply (nothing to do with SA - I've leave you in Brian's capable hands there!), we used to use Vault at Red Gate, and CruiseControl.NET seemed to talk to it nicely. There's a CC.NET plug-in on the SourceGear site: <http://www.sourcegear.com/downloads.html>
I'm not sure CC.NET is particularly actively maintained nowadays, but it's served us relatively well in the past, with a few tweaks here and there!
Hope that helps!
Rob / comments
As a largely off-topic reply (nothing to do with SA - I've leave you in Brian's capable hands there!), we used to use Vault at Red Gate, and CruiseControl.NET seemed to talk to it nicely. There's a...
Just to follow up on that a bit further: the reason SQL Search doesn't support SQL Server 2000 is that the way metadata is stored changed significantly between 2000 and 2005.
SQL Server 2000 used real tables dbo.sysobjects, dbo.syscolumns and friends, whereas 2005 and later uses the views sys.objects, sys.columns (and many others) which have a rather different schema.
It'd therefore be a significant amount of work to populate SQL Search's internal object model from the 2000-style tables.
Many thanks,
Rob / comments
Just to follow up on that a bit further: the reason SQL Search doesn't support SQL Server 2000 is that the way metadata is stored changed significantly between 2000 and 2005.
SQL Server 2000 used r...
Hi,
It seems like there's issues selecting in the object explorer in non-English versions of SSMS (SDI-40 for our reference); I've logged the SSAS issue as well (SDI-50), but don't have an SSAS instance to hand, so we'll need to investigate that one further.
Thanks for the comments - we'll let you know when we make some progress on those issues.
Many thanks,
Rob / comments
Hi,
It seems like there's issues selecting in the object explorer in non-English versions of SSMS (SDI-40 for our reference); I've logged the SSAS issue as well (SDI-50), but don't have an SSAS ins...
Interesting - I'll have to investigate that one further, but it looks like the encrypted sprocs could be the guilty party. The intended behaviour is to ignore them (though the request to decrypt them is noted!), but possibly something's going wrong there...
Thanks,
Rob / comments
Interesting - I'll have to investigate that one further, but it looks like the encrypted sprocs could be the guilty party. The intended behaviour is to ignore them (though the request to decrypt th...
Thanks Dave - received.
There's nothing reported in the logs that would suggest a problem, and it shouldn't be Win7 either (one of the developer's machines was running Win7 x64 Enterprise as well).
So just to confirm, if you do this:
- Select a single DB in the Object Explorer
- Open SQL Search. That should select that DB in the combo box
- Type a couple of characters such that it begins searching
- Wait until you get search results
- Switch to a different DB
- At this point it might start indexing the other DB, but should then give you search results
- Switch back to the first DB
- Here it should almost instantly return results.
If it doesn't, does the progress bar say "searching" or "indexing"?
Out of interest, if you've got multiple copies of SSMS open at once, could you try reproducing it with just the one copy running?
Thanks,
Rob / comments
Thanks Dave - received.
There's nothing reported in the logs that would suggest a problem, and it shouldn't be Win7 either (one of the developer's machines was running Win7 x64 Enterprise as well)....
Hi,
This certainly shouldn't happen, unless you change databases while it's still indexing for the first time (incomplete indexes are discarded if they're cancelled part way through).
If you look in C:\Docs & Settings\<username>\Local Settings\Application Data\Red Gate\SQL Search, there should be some log files - would it be possible to e-mail them to me at robert.chipperfield at red-gate.com, and I'll see if I can see what's going on?
Thanks,
Rob / comments
Hi,
This certainly shouldn't happen, unless you change databases while it's still indexing for the first time (incomplete indexes are discarded if they're cancelled part way through).
If you look i...
Sorry about that :-(
Yes, it should clearly be sorted - it's logged (SDI-43) and fixed, so should be correct in the next release. / comments
Sorry about that :-(
Yes, it should clearly be sorted - it's logged (SDI-43) and fixed, so should be correct in the next release.
Good stuff - those characters at the front are almost certainly unicode byte order marks, in case you're interested! / comments
Good stuff - those characters at the front are almost certainly unicode byte order marks, in case you're interested!