Назад | Перейти на главную страницу

NHibernate не подключается к SQL Server

У меня на сервере работает 3 экземпляра SQL Server (не спрашивайте почему)!

2xSQL Server 2008 Workgroup (по умолчанию и MSSQLServer2) 1xSQL Server Express 2008 R2 (sqlexpress)

Теперь у меня есть служба / приложение Windows, которое запускает процесс в фоновом режиме. Базы данных почти такие же, однако всякий раз, когда я пытаюсь запустить службу на экземпляре MSSQLServer2, NHibernate выдает исключение.

Я проверил свои строки соединений, и мне кажется, что все в порядке, так как я, конечно, смог скопировать другие.

Я сбросил пароль учетной записи, который использую, и проверил, могу ли я подключиться к нему с помощью Management Studio с новыми кредитами.

Я не знаю, что еще проверить. Приложение загружается (поскольку оно создает запись Log4View), но как только оно делает свой первый запрос NHibernate, оно вылетает со следующим дампом и без дополнительного журнала событий:

Описание: Перестал работать

Сигнатура проблемы: Проблема Имя события: CLR20r3 Сигнатура проблемы 01: R2K3ITVW3VUVRUM1CITUNG1NSZBMATAX
Сигнатура проблемы 02: 1.0.0.0
Сигнатура проблемы 03: 4de87428
Сигнатура проблемы 04: NHibernate
Сигнатура проблемы 05: 1.2.0.4000
Сигнатура проблемы 06: 4639a07f
Сигнатура проблемы 07: 2ad Сигнатура проблемы 08:78 Сигнатура проблемы 09: NHibernate.LazyInitialization Версия ОС: 6.0.6001.2.1.0.272.7 Идентификатор локали: 2057

Прочтите наше заявление о конфиденциальности:
http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409

Как вы упомянули, событие журнала не дает много информации.

Исключения LazyInitialization генерируются, если объекты не полностью созданы. Обычно я ожидал появления сообщения об ошибке типа не могу подключиться к базе данных. Следовательно, я ожидаю некоторых недостатков в коде. По крайней мере, я предполагаю, что перед выполнением других действий в спящем режиме, таких как создание экземпляров объектов, не проверяется, было ли успешно установлено соединение с базой данных.

После разговора о некоторых других вещах, связанных с кодом, давайте рассмотрим причину и возможные обходные пути. Я заметил одно отличие: исключения возникают только при подключении нестандартного экземпляра. Думаю, этого нет на стандартном порту (1433).

Может, номер порта жестко закодирован (1433)? Похоже, что приложения работают только с экземплярами по умолчанию. Вы можете попробовать настроить свой экземпляр вручную MSSQLServer2 использовать порт 1433 только для устранения неполадок. Есть ли файлы конфигурации или записи в реестре, где можно указать номер порта? Или номер порта указан в строке подключения? Если приложение действительно жестко запрограммировано для использования экземпляра по умолчанию и / или порта 1433, на мой взгляд, вы как администратор ничего не можете сделать, чтобы заставить его работать со вторым экземпляром.