<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://sqlblog.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Search results matching tags 'Troubleshooting' and 'Installation'</title><link>http://sqlblog.com/search/SearchResults.aspx?o=DateDescending&amp;tag=Troubleshooting,Installation&amp;orTags=0</link><description>Search results matching tags 'Troubleshooting' and 'Installation'</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>Analyzing the errorlog</title><link>http://sqlblog.com/blogs/tibor_karaszi/archive/2012/07/05/analyzing-the-errorlog.aspx</link><pubDate>Thu, 05 Jul 2012 11:53:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:44203</guid><dc:creator>TiborKaraszi</dc:creator><description>&lt;p&gt;How often do you do this? Look over each message (type) in the errorlog file and determine whether this is something you want to act on. Sure, some (but not all) of you have some monitoring solution in place, but are you 100% confident that it really will notify for all messages that you might find interesting? That there isn't even one little message hiding in there that you would find valuable knowing about? Or how about messages that you typically don't are about, but knowing that you have a high frequency can be valuable information?&lt;/p&gt;&lt;p&gt;So, this boils down to actually reading the errorlog file. Some of you probably already have scripts and tool that makes this easier than just reading every simple message from top to bottom. I wanted to share how I do it, and this is why I wrote my&amp;nbsp;&lt;a href="http://www.karaszi.com/SQLServer/util_analyze_sql_server_logs.asp"&gt;Analyze SQL Server&amp;nbsp;logs&lt;/a&gt; article.&amp;nbsp;Check it out. And, feedback is always welcome!&lt;/p&gt;</description></item><item><title>SQL Client config, 32 and 64 bit</title><link>http://sqlblog.com/blogs/tibor_karaszi/archive/2009/09/08/sql-client-config-32-and-64-bit.aspx</link><pubDate>Tue, 08 Sep 2009 11:04:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:16655</guid><dc:creator>TiborKaraszi</dc:creator><description>&lt;P&gt;Say you want to change the preferred netlib connection order. Or add a server alias.&lt;/P&gt;
&lt;P&gt;You can do this using the "SQL Server Configuration Manager" program. But installing this on each client machine where you want to do the modification might not feel that attractive. &lt;/P&gt;
&lt;P&gt;Another option is to use a tool like regmon while doing the config on a reference machine, sniff the registry modifications and then shoot these out&amp;nbsp;to the client machines. This might be overkill, though.&lt;/P&gt;
&lt;P&gt;Yet another option is to use the cliconfg.exe tool, which ship with Windows.&amp;nbsp;This tool is already available on your machine.&amp;nbsp;However, on a 64 bit machine, you need to consider whether the client app is a 32 or 64 bit app. The processor architectore for that app will determine where in the registry the app (client libraries) will look. Below is my results from working on a x64 XP installation.&lt;BR&gt;64 bit (native): HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\SuperSocketNetLib&lt;BR&gt;32 bit (WOW): HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\SuperSocketNetLib&lt;/P&gt;
&lt;P&gt;Razvan Socol was kind enough to enlighten me, a while ago, of the fact that runnig the 64 bit version of cliconfg.exe will modify in the "64 bit" registry entry (as per above) and vice versa for the 32 bit version of cliconfg.exe. Razvan mentioned that starting cliconfg.exe from Run will start the 64 bit version, and from a 32 bit app (Explorer for instance - which I couldn't find how to do, but I'm sure somebody will enlighten me) will start the 32 bit version. &lt;/P&gt;
&lt;P&gt;Above made&amp;nbsp;me wonder in what folder each file is. Here are my findings (on the test machine I was using - a pretty clean XP x64 machine):&lt;/P&gt;
&lt;P&gt;64 bit version of cliconfg.exe: C:\Windows\System32&lt;BR&gt;32 bit version of cliconfg.exe: C:\Windows\SysWOW64&lt;/P&gt;
&lt;P&gt;(And, before you ask, no, above is not a typo. There is some logic behind this. :-) )&lt;BR&gt;&lt;BR&gt;&lt;/P&gt;</description></item></channel></rss>