SQL Server Integration Services (SSIS) запускает SQLDUMPER.EXE и виснет во время выполнения пакета.

Эта проблема возникла у меня почему-то только на Windows7 (на XP все работало нормально). Во время отладки SSIS package на мгновение появлялось DOS-окошко с SQLDUMPER, после чего задачи в Business Intelligence Development Studio оставались желтенькими, но никогда не завершались. Решение этой проблемы такое же странное, как и она сама - надо выключить службу SQL Server VSS Writer.

Источник: http://discussions.virtualdr.com/showthread.php?t=220983

ADODB.Recordset error '800a0e78' Operation is not allowed when the object is closed.

У меня это случилось при миграции старого веб-приложения (ASP) на новый веб и сиквел сервер. Были изменены параметры подключения (с ODBC на OLE DB). Приложение подключалось к базе данных, SQL Profiler показывал, что команды исполняются, однако часть кода

set objDBConnection = Server.CreateObject("ADODB.Connection")
Set objRs = Server.CreateObject( "ADODB.RecordSet")
objDbConnection.Open(ConnectionString)
objRs.Execute("EXEC someStoredProcedure")

возвращало закрытый объект objRs и ошибку ADODB.Recordset error '800a0e78' , чего не случалось до миграции.
Немножко поковырявшись и погуглив, нашел следующее: вызовы stored procedures, сделанные через ODBC не возвращают "(x) rows affected", а OLE DB - возвращают. Соответственно, встретив эту строчку в ответе, OLE DB неверно интерпретирует ее как отсутствие данных и закрывает объект. Починить это можно двумя способами - поставив SET NOCOUNT ON вначале кода stored procedure (более правильный способ) или включив no count глобально на уровне сервера (на уровне базы данных, к сожалению, этого не сделать).
В связи с этим приходит следующая мысль: обязательное использование SET NOCOUNT ON в начале кода stored procedure - это хороший тон.

Источник: http://tutorials.aspfaq.com/8000xxxxx-errors/why-do-i-get-800a0cc1-errors.html

SQL Server Management Studio at x64 platform ('System.OutOfMemoryException', memory leaks, etc.)

Не успел я порадоваться на свой новый лэптоп (Elitebook 8540w, 8GB RAM), как заметил, что SSMS ведет там себя очень странно - зависает, работает ощутимо медленнее, чем на моем старом лэптопе и периодически отъедает 1-2GB RAM на очень простых запросах.
Дня два копал интернет, пока не нашел следующее:
"...You may experience slow performance when you run 32-bit SQL Server tools on 64-bit operating systems..."

"...To improve performance, run these 32-bit tools on a computer that is running a 32-bit operating system. Then, connect to a 64-bit server that is running SQL Server..."
В результате получается, что мой новый лэптоп несовместим с моим основным рабочим инструментом.
Не понимаю я Microsoft - почему, несмотря на то, что все новые версии ОС объявлены x64, инструменты разработчика даже для SQL 2008 R2 все еще x32?
Источник: http://support.microsoft.com/?id=906892

An attempt to start/stop instance of service Windows SharePoint Services Web Application on server did not succeed.Re-run the action via UI or command line on the specified server. Additional information is below.

'<' is an unexpected token. The expected token is '='. Line 54, position 7.

или

'<', hexadecimal value 0x3C, is an invalid attribute character. Line 81, position 7.

Блоги и форумы стыдливо молчат по поводу этой ошибки, хотя о ней спрашивают.
Причина проста - некоторые программы повреждают XML-файлы при открытии. В данном случае поврежден файл web.config, находящийся по C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\CONFIG

Server Extension 2002 corrupts MS WORD documents during downloading (Server Extension 2002 повреждает файлы MS WORD при скачивании)

Симптомы волшебные, как всегда. Присутствует plain-html static веб-сайт, проще некуда, куда пользователь закачивает документы в формате Microsoft Word и редактирует странички при помощи Microsoft Frontpage. Если скачивать эти документы из папки напрямую, то все ОК. Если пробовать их скачать через ссылку на веб-сайте - файл оказывается поврежденным и короче на 1 байт.
Сравнив работающий и неработающий файл, я выяснил, что в файле присутствует hyperlink, содержащий строчку "https://". В неработающем файле эта строчка была заменена на "http://", что нарушило CRC.
Я не могу сказать точно, что повреждает файл, но на других серверах без Server Extension мы никогда не имели такой проблемы. Так что решим, что это виноват он.
Проблему решили заменой "https://" на "http://" в документах.

OLE DB provider 'SQLOLEDB' was unable to start a distributed transaction.

В интернете полно решений по поводу этой задачи. 99.9% из них просто перепечатывают следующую статью:
http://support.microsoft.com/kb/873160
Но что делать, если мы все вышеперечисленное сделали, а оно не работает?
Нигде я не нашел упоминания о том, что для корректной работы MS DTC требуется, чтобы все хосты, участвующие в распределенной транзакции, могли разрешать имена друг друга в NetBios. Если у них разные DNS-серверы или они в разных доменах, это может стать проблемой. В таком случае достаточно прописать имена друг друга им в host файлах или использовать любое другое аналогичное решение.

Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]

Опять забавные симптомы: можно подключиться к SQL серверу удаленно, но если попробовать подключиться локально - доступа нет, в event log эта ошибка. Решается просто - выключением UAC либо right click - Run as Administrator.