К списку форумов К списку вопросов
OFF/2 УРБД+Журнал расчетов+SQL+"Cannot insert duplicate key row"?
pvase
01.10.2004 - 15:01
Такая вот проблемка возникла, причем ЦБ в dbf (чтобы пошустрее проводить последовательность) а все пееферийные в SQL. Так вот сегодня произошел такой трабл, что никуда не грузиться автообмен, выдает:
CBљ SQL State: 23000
Native: 2601
Message: [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot insert duplicate key row in object 'CJ2667' with unique index 'ID'
Как с эитм бороться в SQL знаю, но ведь ЦБ в dbf.
Проблема2, в SQL в джурнале расчетов только один индекс "ROW_ID" в dbf такого поля нет, какое поле отвечает за индекс в журнале расчетов в dbf?
p.s. Насколько я понял, надо найти этот дубль и его удалить, но по какому полю искать не пойму.
toypaul
1 - 01.10.2004 - 15:33
по всем у которых уникальный индекс есть
pvase
2 - 01.10.2004 - 15:35
Плиз, помогите, как исправить, народ уже пол дня автообмен загрузить не может. Как удалить дубль в dbf, какое поле смотреть (60 000 записей, все просматривать можно долго и нудно).
ТакиеДела
3 - 01.10.2004 - 15:39
используй объект xbase
БЖ
4 - 01.10.2004 - 15:43
0, сделай одинаковыми периоды рассчетов во всех базах.
pvase
5 - 01.10.2004 - 15:55
(1)
вот поля индексов, наскидку, каке проверить?
# Name |Descr |Unique|Indexed fields |DBName
I=IDDOC+PER| |0 |IDDOC,PERIOD,IDS,ORDER |IDDOC+PERIO
I=PERIOD+ID| |0 |PERIOD,IDS,ORDER,DATEB |PERIOD+IDS+
I=IDS+PERIO| |0 |IDS,PERIOD,ORDER,DATEB |IDS+PERIOD+
I=ID | |0 |ID |ID
I=IDS+DATEE| |0 |IDS,DATEE,ID |IDS+DATEE+I
I=DATEE+ID | |0 |DATEE,ID |DATEE+ID
I=IDPARDOC | |0 |IDPARDOC |IDPARDOC
I=IDRECALC | |0 |IDRECALC |IDRECALC
I=FF2427 |FF2427 |0 |FF2427,PERIOD,IDS,ORDER,DATEB |FF2427
pvase
6 - 01.10.2004 - 16:00
(4) Не помогло, ошибка таже, даже после установки одного преиода журнала ЗП в базах (переферийные+ЦБ).
MichealStar
7 - 01.10.2004 - 16:03
C SQL давно не тр. duplicate key- но ругался он так только на ID объекта (в случае ЗП думаю это запись) и индексы тут не при чем. Счас прогляжу...
fisher
8 - 01.10.2004 - 16:06
2(0) Достаточно перепровести проблемный документ (на котором вываливается ошибка).В журнале регистрации можно выкупить последний успешно загруженный. Следующий можно посмотреть непосредственно в файле обмена.
ЗЫ. Невнимательно смотрел. По журналу расчетов в SQL дохрена индексов, в том числе и "ID". Индексы в DBF и SQL почти одинаковые.
pvase
9 - 01.10.2004 - 16:11
(8) Делал, не помогло, ошибка "перескакывает" на следующий документ.
Индексы то одинаковые, но уникальный в SQL только 1 - ROW_ID, а вот в dbf такого нет, и откуда SQL генерит этот ROW_ID не могу понять.
fisher
10 - 01.10.2004 - 16:20
+(8) Поле так и называется - ID. Индекс одноименный.
2(9) Повторяю - невнимательно смотришь. Именно "ID" а не "ROW_ID" и он уникальный. А ROW_ID в SQL - тот вообще кластерный. Только дело не в нём, а в том, что ID переприсваивается каждый раз при перепроведении дока. И из-за дебильной схемы присвоения (явный ляп 1С, который до сих пор почему-то не исправлен) иногда получаются одинаковые ID в разных базах для разных записей ЖР.
ЗЫ. Значит, перепровести нужно все соотв. документы. А шо робыты?
fisher
11 - 01.10.2004 - 16:22
+(10) Все индексы ЖР - уникальные.
БЖ
12 - 01.10.2004 - 16:25
6, странно. должно помочь. сталкивался с таким. делал так. Устанавливаел период рассчета во всех бд одинаковый. потом из центра выгрузка в перефириях загрузка.
PS тогда тоже было ринулся в сиквеле колупать. :)
pvase
13 - 01.10.2004 - 16:26
(10) А в какой БД, в Центральной, в в создателе или в той, куда не хочет загружаться (это 3 разные БД)?
Миграция - Все информационные базы.
fisher
14 - 01.10.2004 - 16:29
2(13) В данном случае налицо совпадение в базах отправителя (ЦБ) и получателя (куда не хочет загружаться). Достаточно перепровести доки в базе получателе (при этом записям с ID-дублями присвоятся новые ID) и заново попытаться загрузить ту же обменку.
pvase
15 - 01.10.2004 - 16:34
(14) 18 филиалов (переферийніх ИБ), в одну грузиться автообмен (где и были введены документы), а в другие - нет, Если перепровести во всех ИБ - то о колизиями что будет?
fisher
16 - 01.10.2004 - 16:34
Во избежание подобных глюков, лучше в центре вообще не трогать зарплатные документы филиалов.
fisher
17 - 01.10.2004 - 16:38
2(15) Хм... У тебя что, все видят зарплату всех?
ЗЫ. С коллизиями ничего не будет. Загружена будет версия ЦБ на данный момент.
fisher
18 - 01.10.2004 - 16:43
Да. Вижу что так и есть (просмотрел в (13)).
Это не есть гуд. Каждый раз когда дергают чужие зарплатные документы возникает вероятность повторения этой бяки.
Чтобы не мучиться в каждой периферии, можно попробовать перепровести эти доки в центре и повторить обмен. Но 100% гарантии в этом случае нет.
pvase
19 - 01.10.2004 - 17:37
(16) Это из-за архиваирования периода. Дело в том, что при архиваировании документов файл автообмена грузился день, в итоге было приянто решения выгружать все ИБ заново. После чего, конечно ЗП с натсройками "ИБ создания и Центр" никуда не выгрузилась. Пришлось ставить миграцию на всех.
nikka
20 - 01.10.2004 - 18:11
Недружба связки УРБД - расчет известен. На климорге кто-то рассказывал как обошел (у него постоянно вылетала скульная версия при обмене), но я сейчас не помню, кажется выгружал в дбф потом обменивался, потом грузил опять в скуль. Поищи там, если поможет. Но геморрой страшный, поскольку БЖ права, с периодами постоянные проблемы.
fisher
21 - 01.10.2004 - 18:22
ИМХО, к периодам эта проблема никакого отношения не имеет.
Буду рад аргументированным возражениям.
БЖ
22 - 01.10.2004 - 19:02
21, фиг его знает точно, но скорее всего тут путанница в полях, на которые ссылается _1SUPDTS. Возможно ссылается на IDDOC вместо ID (таблица CJXXXX). К сожалению не могу щас протестить.
fisher
23 - 01.10.2004 - 19:07
2(22) Подумай еще раз. На IDDOC и должно ссылаться. В _1SUPDTS фиксируются изменения зарплатных документов, а не записей ЖР. Запись ЖР не является самостоятельным объектом миграции. Записи мигрируют только как движения зарплатных документов (полная аналогия с движениями регистров).
БЖ
24 - 01.10.2004 - 19:13
23, всегда думаю только один раз, второй раз думаю уже совсем о другом. :)
пробовать надо, а не воду в ступе месить, а так всё это домыслы.
fisher
25 - 01.10.2004 - 19:26
(24) Домыслы, подтверждающиеся практикой, имеют силу рабочей гипотезы ;)
ИМХО, проблема в том, что префиксом в ID записи ЖР является имя базы, в которой был создан зарплатный документ, которому принадлежит данная запись. При перепроведении чужого зарплатного документа старые записи ЖР удаляются (аналогично движениям и проводкам) и записываются новые. При этом им присваиваются новые ID (очередные). Налицо возможность совпадения этих ID с ID новых записей ЖР, созданных на родине зарплатного документа в промежутке между обменками.
Во всяком случае я себе это представляю именно так ;) Но это не пустые домыслы, т.к. я пробовал, а не воду в ступе месил.

К списку вопросов на форуме 1C

>>