![]() |
![]() |
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 новых записей ЖР, созданных на родине зарплатного документа в промежутке между обменками. Во всяком случае я себе это представляю именно так ;) Но это не пустые домыслы, т.к. я пробовал, а не воду в ступе месил. |