Имя: Пароль:
1C
1С v8
Ошибка SDBL: Ожидается выражение (Pos=1380)
0 Alex_Rav74
 
29.06.16
08:49
База УПП 1.3, SQL 2008

После ТиИ при попытке зайти в документ ОПЗС выдаёт: "Ошибка SDBL: Ожидается выражение (Pos=1380)" (И две кнопки "Завершить работу" и "Перезапустить")

Установил платформу 8.3.8.1784, почистил ВСЕ кэши - те же яйца.
Работа с 1С происходит с двух терминальных серверов.
Но есть единственное "НО" - под учётками, у которых были Полные права с терминального сервера №1 в ОПЗС заходит, а с сервера №2 - нет.
1 lxs
 
29.06.16
08:57
Нажми Я.
2 Alex_Rav74
 
29.06.16
09:00
А "выражение" играет роль? А то по 1380 нет ссылок.
3 hhhh
 
29.06.16
09:07
(2) это какой-то запрос в документе ОПЗС ерундит. У вас там полностью типовое в этом документе?
4 Alex_Rav74
 
29.06.16
09:11
(3) ОПЗС дописан
5 hhhh
 
29.06.16
09:14
(4) ну вот, копайте в эту сторону. Берите утюг, паяльник и приступайте к автору этих дописок. Чего он там наваял?
6 AlfaDog
 
29.06.16
09:16
Чисти везде кэш. Перезагружай серваки 1с и SQL.
7 Alex_Rav74
 
29.06.16
09:17
(6) Это уже сделано
8 Alex_Rav74
 
29.06.16
09:20
(6) Почистил кэш у пользователя, который мог заходит в ОПЗС, то же стала выходить ошибка.
9 lxs
 
29.06.16
09:38
У меня недавно была похожая тема: в процессе обновления конфигурации вырубился ноутбук. зачем понеслись ошибки sdbl. Проверка утилитой ошибок не выявила. ТИИ нашло кучу битых ссылок. Попытки реанимировать базу оказались безуспешными, в некоторых случаях база полностью разрушалась, в других очищались все данные. Восстановил из бэкапа.

P.S. Файловая. Типовая. ЗУП Базовая.
10 piter3
 
29.06.16
09:45
Файловая это вообще алес с точки зрения безопасности хранения.В тестовах целях еще можно,а на продуктиве это эсктремальный вид спорта
11 AlfaDog
 
29.06.16
09:52
(8)  Что было сделано до всплытия ошибки.

Конфу не менял? реструктуризацию не делал?

У меня такое было когда конфа 1с не соответствовала структуре БД в SQL. (рухнула при реструктуризации) Полазил в SQL руками , удалил табличку лишнюю вылечил базу.
12 Alex_Rav74
 
29.06.16
10:17
(11) Удаление помеченных объектов, ТиИ и всё
13 lxs
 
29.06.16
10:19
(10) Ну, если в базе учет по одной организации, один пользователь и сама база 1 Гб с учетом веса конфы, то, понимаешь же, вопрос о переводе на SQL такой малышки не стоит вообще. Но я с тобой согласен. Файловые базы небезопасны. Их надо постоянно бэкапить.
14 AlfaDog
 
29.06.16
10:23
попробуй в документ "ОПЗС" добавить пустой реквизит. Посмотри пройдет или нет реструктуризация
15 lxs
 
29.06.16
10:32
(14)+ только на всякий случай базу заархивируй)
16 Alex_Rav74
 
29.06.16
10:46
Сделал архив базы и развернул в фаловую - та же ошибка выходит
17 lxs
 
29.06.16
10:47
(16) Архив есть?
18 Alex_Rav74
 
29.06.16
10:47
(17) есть ночной - делал перед ТиИ
19 lxs
 
29.06.16
10:50
(18) Надо было его сразу развернуть, А с этой базой уже играться.
20 hhhh
 
29.06.16
10:50
(16) всё-таки посмотрите запросы, которые дописали. Фигнёй ведь занимаетесь.
21 Alex_Rav74
 
29.06.16
10:51
(19) ошибка выявилась только через 2 часа после начала работы
22 Alex_Rav74
 
29.06.16
10:52
(21) Запрос, если и изменялись, то в движении и заполненении, а при открытии всё типовое.
23 lxs
 
29.06.16
10:54
(21) Ты читал мою ситуацию? На мой взгляд логичнее восстановить последнюю рабочую версию в тех условиях, когда база работала стабильно (имею ввиду релиз платформы), а уже с текущей базой (поломанной) играться.
24 Alex_Rav74
 
29.06.16
11:02
Значит: запустил ТиИ на файловой - выдаёт ошибку: Ошибка SDBL: Fld35402 не является именем поля
25 AlfaDog
 
29.06.16
11:08
(24) Ну я так и думал. Структура конфы не совпадает со структурой БД.
26 AlfaDog
 
29.06.16
11:09
Лечу такие базы, за скромную плату.
27 фобка
 
29.06.16
11:09
выгрузка/загрузка
28 Alex_Rav74
 
29.06.16
11:12
(26) В тестовой базе помог твой совет (14). Сча пробую в рабочей.
29 lxs
 
29.06.16
11:13
(26) какой ты меркантильный
30 Alex_Rav74
 
29.06.16
11:33
Всем спасибо. Всё ок.