Добрый вечер!

Конфигурация самописная.
Началось все с ошибки в режиме предприятия:

"{Обработка.РаботаСЗаказом.Форма.Форма3.Форма(733)}: Ошибка при получении значения атрибута контекста (ВалютаСС)
   Если ((ДанныеСтроки.Ссылка.ВалютаСС = Справочники.Валюты.Валюта И Константы.ВыделятьRUR.Получить()) ИЛИ (ДанныеСтроки.Ссылка.ВалютаСС = Справочники.Валюты.Валюта1 И Константы.ВыделятьEUR.Получить())) Тогда
по причине:

по причине:
Ошибка использования операции 'ОБЪЕДИНИТЬ' ('UNION'). Допустимо объединение не более 256 результатов запросов
Ошибка использования операции 'ОБЪЕДИНИТЬ' ('UNION'). Допустимо объединение не более 256 результатов запросов"

Полез разбираться.
Попытался сделать Тестирование и Исправление со всеми галочками, но вылетает с ошибкой:
"Попытка вставки неуникального значения в уникальный индекс:
Microsoft OLE DB Provider for SQL Server: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем "dbo._AccRgAT21589" и индекса с именем "...... бла бла бла"

Выгрузка информационной базы тоже не работает. Вылезает ошибка
"Ошибка разделенного доступа к информационной базе." Запущен сеанс Конфигуратор.

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

Что можно попробовать ещё сделать?

Зоопарк из глупости, ошибок и кривых рук.

<<интересно, а почему всякая жопа случается ночью? жопа - это ночное животное днём оно крепко спит а по ночам выходит полакомиться кривыми руками>> ©bash

может в сеансах закешировалось?
имею в виду сервер предприятия.

(2) *опа случается потому, что серьезные дела на ночь глядя не делаются - усталость плохой помощник.

а вместо ДанныеСтроки.Ссылка.ВалютаСС просто ВалютаСС написать не судьба была?

база в режиме предприятия запускается вообще?

H A D G E H O G s, обоснуйте пожалуйста свои слова.

Ошибка случилась утром, вечером не работают пользователи, поэтому разбираюсь сейчас.

В режиме предприятия в целом кроме того одного документа база работает идеально.

В Сеансах в консоле сервера предприятия ничего нету.


Давайте не будем сейчас разбирать код, его писал не я. Ошибка системного характера.

попробуйте удалите документ непосредственно

и вообще в чем собстно проблема-то? база не открывается, документ не прводится или что?

Проблема как минимум в том что не выгрузить базу в *.dt

Про ошибку с документом я написал просто так, вдруг кого на какие мысли наведёт.

(10) ну тады форматни диск, где скуль стоит - вдруг на какие мысли наведёт.

(11) очень остроумно!

(6)

1) 256 таблиц лечатся через ВЫРАЗИТЬ(), ну и правильным проектированием. Это ошибки.

2)  CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем "dbo._AccRgAT21589".
Это кривые записи в таблице остатков. Лечится
а) Пересчет итогов без реиндексации, реиндексацией
либо
б) Отключением итогов, реиндексацией, включением итогов.
Это кривые руки.

3) <<Выгрузка информационной базы тоже не работает. Вылезает ошибка
"Ошибка разделенного доступа к информационной базе." Запущен сеанс Конфигуратор.>>

Эта баян во язытцах и не раз обсосанный. В поиск.
Это глупость.

(13)
1) В этом коде нечего выражать, там и так всё одного типа. Почему ругается непонятно, говорю же ошибка на уровне системы где-то

2) Пересчет итогов зависает.
Отключение итого и переиндексация вызывает туже ошибку.

3) В поиске в основном метод решение этой проблемы - это перезапуск служб СКЛ и Сервера. Я это пробовал, всё равно тоже самое.
Как будто где-то в базе прописано что запущен сеанс конфигуратора, но он не идентифицируется как текущий.

(14) по 3 [то перезапуск служб СКЛ и Сервера]
это не так
/3 Gb помогает в 90% случаев
в остальных мелкая хирургия на сиквеле, а именно удаление конфигурации поставщика, описанная Гилевым

2(14) да с чего вы взяли что это основной метод решения? Это не основной, а просто первое что нужно сделать. И если не помогло - делать следующее

(16) и ногами, ногами

http://www.gilev.ru/1c/memleak/memorymore.htm
Описанное тут тоже пытался проделать
Проверка ссылочной целостности тоже вываливается с ошибкой.
/3 Gb как то могут помочь на 64 битной системе?

После того, как вручную удалил в SQL запись при открытии которой вылезала ошибка
"Ошибка использования операции 'ОБЪЕДИНИТЬ' ('UNION'). Допустимо объединение не более 256 результатов запросов"

Теперь проверка логической целостности проходит нормально, но остальные проблемы остались.

(19) Зачисть таблицу итогов руками.

(19) В сиквеле.

(20) Как её найти? как она может называться?

(22) ну, типа total

Ну типа _AccRgAT21589

(22) перед этим отключить расчет итогов попробуй

А кто Вам сказал, что с остановкой сервера 1с, останавливаются процессы? Остановите севрер 1с, запустите менеджер задач и остановите процессы вручную. Зависшее подключение должно уйти. Запустите сного сервер1с "Ошибка разделенного доступа" при этом перестанет появляться, скорее всего.

(26) Да я даже пробовал перезагружать и менять сервер через *.bak SQL так что тут не в процессах дело

(27) темпы все почистите. На всех других компах процессы проверьте.

(27) Я не про перезагрузку, читайте внимательно.

(19) Зачистка таблицы итогов идёт больше 8 часов, не дождался отключил.
(25) А как отключить расчет итогов по вашему? Может мы о разных вещах говорим?
(29) Пробовал останавливать, процессов с 1с при этом не было.

В итоге чего удалось достичь:
Я проводил переиндексацию и на те индексы на которых были ошибки я в MSSQL перестроил и реорганизовал индекс. Некоторые записи и таблицы пришлось удалить в скуле.
В конечном итоге тестирование и исправление прошло полностью со всеми галочками.

Но так и не получается выгрузить базу. Мешает это соединение, которое непонятно откуда берётся.

Удали базу через консоль Администрирования и подключи заново. Можно под тем же именем

+31 только удали из списка, а не совсем...

(31) тоже самое

2(30) выгрузить именно в Дтшник? сохранить конфу в Waybr получается?

(34) Waybr - это что?
Просто сохранить конфигурацию в Конфигураторе получается. Получается даже обновлять её не динамически.

(34) выгрузить да, именно в дтшник

2(36) в общем фигово... сервер 1С 32-битный? в базе данных хранятся здоровые файлы например или какие-то другие двоичные данные, короче большие?

или скажем так - можешь ли ты подозревать, что в ИБ хранятся какие-то большие данные, в смысле в одной записи, в одном поле, а не вообще там - много документов?

(37) Сервер 64-битный, пробовал так же 14 релиз.
Нет, такого не хранится в базе.

если 64-битный и выгрузка не происходит, тогда совсем фигово... Рекомендую настроить ТЖ и ловить события при попытке выгрузке.. Сначала все, потом например те, которые длятся более минуты, потом например запросы выполняемые СУБД, то есть как-то локализовать на чем застревает при выгрузке. Может это таблица какая-то, или СКЛ-серверу чего-то не хватает - угу?

(37) есть конечно
конфигурация поставщика
у ТС наверняка УПП

2(41) хм... тогда сомнения что 1Ссервер 64-битный; ну
хорошо...
Пусть автор выполнит запрос
SELECT FROM dbo.Config WHERE DataSize > 125829120
в консоли СКЛ к именно этой базе

(41)[тогда сомнения что 1Ссервер 64-битный]
разрядность и доступная память ни как не связаны

а, ну вообще тоже верно

(44) подождём, пока ТС на копии снимет конфу целиком  с поддержки и получим ответ

(41) Конфигурация самописная, писал в первом посте, не самая большая.
Из данных есть только одна таблица с логом действий пользователя (справочник) в которой много информации.

(42) SELECT FROM dbo.Config WHERE DataSize > 125829120
найдено 0 строк

тогда без ТЖ это гадание на кофейной гуще... даже и с ТЖ это гадание, но хоть как-то наукоподобное.

Извините за глупость, ТЖ - это что и как его запустить?

Технологический Журнал. ищите инфу на ИТС и в инете, она есть

При выгрузке в Просмотре событий Windows возникает событие от MSSQL

"Ошибка чтения большого объекта при отправке данных клиенту. Обычно причина этой ошибки заключается в том, что приложение работает с уровнем изоляции READ UNCOMMITTED. Данное соединение будет прервано."

это уже лучше... но все равно что за объект можно выяснить через (49)

Если кому интересно проблему решил так:
-DBCC CHECKDB ("Имя_базы", [repair_allow_data_loss])
-Реорганизаций некоторых индексов
А со стороны 1с перепроведением всей базы и пересчетом итогов.