|
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
|
всем спасибо! Все заработало!
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |