Архивы по Категориям: sql

доступ к базе данных на сервере возможен только из одного каталога

«Такая ошибка возникает при попытке загрузить версию 1С для SQL после того, как один из пользователей некорректно вышел из системы. В редких случаях эта ошибка может быть результатом некорректной установки конфигурации.»


Простой случай:

а)Принудительно остановить SQL-процесс можно с помощью SQL Enterprise Manager. В нем все активные процессы перечисленны в ветке “Management\Current Activity\Process Info”. Надо найти в списке справа процесс, который мешает жить, выделить его и в меню “Action” выбрать пункт “Kill Process”

б)Если пользователи работают по протоколу Named pipes, то можно просто закрыть файлы на SQL-сервере, открытые повисшим пользователем. Такие файлы имеют вид \PIPE\MSSQL$NAMEDSERVER\SQL\query. (смотреть в открытых файлах, управления компьютером)

в) Можно поступить жестче и выполнить скрипт:

USE [master]
ALTER DATABASE [наша база] SET OFFLINE WITH ROLLBACK IMMEDIATE

после выполнения скрипта рестарт службы SQL и выполнить скрипт:

USE [master]
ALTER DATABASE [наша база] SET ONLINE

Тяжелый случай:
косяк с самой базой. это печально.
Делаем бекап базы!!! (mdf и ldf файлики)

открываем query analizer
для начала переводим базу в сингл моде:

sp_dboption ‘ВАША БАЗА‘,’single user’, true

Чекаем базу:

DBCC CHECKDB (‘ВАША БАЗА‘, REPAIR_ALLOW_DATA_LOSS)

Если на этом все заканчивается, то поздравляю — вам повезло! Переводите в мультиюзер и вперед.

Если нет и говорит чтото подобное:
Server: Msg 602, Level 21, State 16, Line 1
Could not find row in sysindexes for database ID 7, object ID СТРАШНАЯЦЫФРА, index ID -1. Run DBCC CHECKTABLE on sysindexes.

Это очень печально
Узнаем что за таблица женской писей накрылась:

select object_name(СТРАШНАЯЦЫФРА)

Если это _1SCONNECT — поздравляю — это лечится.

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[_1SCONNECT]’) and OBJECTPROPERTY(id, N’IsUserTable’) = 1)
drop table [dbo].[_1SCONNECT]
GO

CREATE TABLE [dbo].[_1SCONNECT] (
[CONNECTUUID] [char] (36) NOT NULL
) ON [PRIMARY]
GO

затем:

EXEC sp_configure ‘allow updates’, ‘1’
RECONFIGURE WITH OVERRIDE
GO
delete from sysobjects where name=’dummy’
GO
EXEC sp_configure ‘allow updates’, ‘0’
RECONFIGURE WITH OVERRIDE
GO

потом снова:

DBCC CHECKDB (‘ВАША БАЗА‘, REPAIR_ALLOW_DATA_LOSS)

может выдать ошибки, но уже в других таблицах, если так — то все идет по плану.

Еще раз чекаем:

DBCC CHECKDB (‘ВАША БАЗА‘, REPAIR_ALLOW_DATA_LOSS)

Ошибок нет? Переводим в мульти-режим:

sp_dboption ‘ВАША БАЗА‘,’single user’, false

Наслаждаемся.
Сработало это по той причине что без данных из _1SCONNECT вполне можно жить и мы ее тупо грохнули и пересоздали. Если же такой косяк вызывает таблица с ценной информацией…