Имя: Пароль:
1C
1C 7.7
v7: Проблема при восстановлении ЗиК SQL после некорректного обновления.
0 Drac0
 
28.10.11
13:24
Добрый день. Поставил обновляться ЗиК SQL. После того как почти 5 часов провисело обновление решил его-таки убить, т.к. работать надо, а когда закончится - хз. После этого восстановил ночной бэкап SQL, закинул в папку с базой прежний MD и DDS (в NEW_STRU оказались новые, хоят повторное обновление или объединение не запускал). После этого при запуске конфигуратора начинается инициализация таблиц и прочее и доходит до Пересчет ссылок по графе отбора "Сотрудник" и уходит далеко вперед. Думаю, из-за этого обновление и закосячилось. В итоге не удается запустить бэкап. Что можно сделать в данной ситуации? Выгрузка из 1С есть. Пока разворачивается тоже.
1 filh
 
28.10.11
13:30
>>ЗиК SQL
жесть!
2 filh
 
28.10.11
13:31
и бекапы не делают перед обновлением, еще больше жесть!
3 filh
 
28.10.11
13:31
а вообще, пятнично!
4 SnarkHunter
 
28.10.11
13:34
(1)Это не жесть, это нормально...
(0)Найди документ с датой из будущего и убей его...
5 ДенисЧ
 
28.10.11
13:35
(4) как же он найдёт его, если у него пересчёт зависает? :-)
А со скулем он работать, не умеет...
6 Drac0
 
28.10.11
13:36
да уже нашел 8011 год.
бэкап был 1сный. но при его загрузке все-равно пересчет идет...
7 SnarkHunter
 
28.10.11
13:37
Ну тогда надо специалиста звать...
8 Drac0
 
28.10.11
13:37
(1) знаю, выбиваю терминальныфй сервер для перевода на файловую версию. прошлый так сделал чтобы гемморя с бэкапами не иметь...
9 ДенисЧ
 
28.10.11
13:37
(6) Загрузи бекап. Когда начнёт пересчитывать - убей конфиг. Зайди в скуль. Поправь дату документа. Запусти конфигуратор - он сам начнёт считать.
10 Drac0
 
28.10.11
13:38
(9) попробую
11 Drac0
 
28.10.11
13:51
(9) А вот теперь можно кидаться какашками. Нашел в таблице SQL нужный документ, а вот как его дату можно вручную поправить?
12 Drac0
 
28.10.11
14:16
мде, есть нюанс. Поменять дату документа недостаточно, необходимо поменять номер, иначе не будет уникальности. интересно, в какой таблице хранятся номера документов ...
13 filh
 
28.10.11
14:17
в журнале
14 filh
 
28.10.11
14:19
jq)
15 filh
 
28.10.11
14:19
16 DJ Anthon
 
28.10.11
14:22
я вообще не понимаю, почему в типовых нет элементарной проверки в момент обновления на наличие таких доков..
17 Drac0
 
28.10.11
14:25
хм, похоже вообще у меня туго. Почему банальный запрос

SELECT     *
FROM         _1SJOURN
WHERE     (IDDOC = 'I4L')

не возвращает записей. ИД нужного дока точно I4L
18 Ёпрст
 
28.10.11
14:27
(17) ёпта.. iddoc имеет размерность 9
19 Drac0
 
28.10.11
14:28
(18) епрст, а ведь точно. Забыл :)
20 Drac0
 
28.10.11
14:35
все равно не ищет
SELECT     *
FROM         _1SJOURN
WHERE     (IDDOC = '      I4L')
21 antoneus
 
28.10.11
14:48
пробелы не так стоят.
where iddoc like '%I4L%'
как вариант
22 Ёпрст
 
28.10.11
14:56
(20) ясен пень, пробелы не в начале же
23 Drac0
 
28.10.11
14:57
(21) Спасибо, все сработало. А после корректировки _1SJOURN надо ли корректировать _1SCRDOC ? Там тоже дата ребенка содержится. Или она автоматом. Просто сейчас не получается этот док найти в таблице _1SCRDOC.
24 Ёпрст
 
28.10.11
14:58
(23) это табличка подчиненных доков и граф отбора, что ты там в ней корректировать собрался ?!
25 Drac0
 
28.10.11
14:59
Я знаю, для чего эта таблица. Просто атм есть колонка CHILD_DATE_TIME. В ней тоже дата косячного дока. Или она по ссылкам меняется?
26 Drac0
 
28.10.11
15:00
или пересчет как раз эту таблицу и формирует?..
27 Drac0
 
28.10.11
15:16
всем спасибо! Все заработало!
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший