при проведении документа выдает такую ошибку
http://s07.radikal.ru/i180/1207/88/72ee76f660fc.jpg
(не могу ее тут набрать всю)))))

вчера были такие попытки вылечить:

сделала архив, затем ТиИ, выгрузку-загрузку
пару документов проводит, потом опять выдает эту ошибку, жму Ок, появляется окно Невосстановимая ошибка базы - и вылетает

что делать-то, чем лечить?

пс вот заново зашла, вроде проводит нормально
вчера тоже то работало, то вылетало

(131) а эти самые "error messages" - были? на второй закладке...

(130) ну это для вас по-русски, а для меня по-русски будет "открываешь то-то, заходишь туда-то")
ну я просто его в папке нашла, он же так просто не открывается, его надо через EM открыть?

134 - блокнотом, фаром, тоталом - чем угодно. он текстовый

(135) ну я открыла этот страшный файл и там ссылок на DT782 миллион, если поиском искать... что давать-то?

Миллион их быть не может - три в описании, три-четыре в индексах..
интересует PK_DT782

# Name                           |Descr         |Unique|Indexed fields                                              |Type      
I=PK_DT782                       |of IDDOC+LineN|1     |IDDOC,LINENO_                                               |1          
#

так?

на новых документах еще не спотыкалась ни разу, только если в созданный добавляла... но новых было пару штук всего

А сколько строк в документе?
Ну не должно валиться

(140) к двум-трем строчкам добавляю еще 8-12, итого до 20-ти строк в доке

фигня какая-то...

если б больше 9999...

да и то это на файловой

повторюсь, предварительно набила некоторый товар в документы, по паре строк, потом взялась добивать до нужной суммы и начало валиться... отменила все последующие доки и стала проводить по одному... то проводит, то выкидывает

работаю там одна

вот снова вылезла
http://gyazo.com/962439f80d437d0aa24268e4743fc82d

при том, что в этот док я уже что-то добавляла, он провелся, потом открыла, еще добавила, жму ок и ошибка и жмешь Ок и вылетает

вроде одинаковая ошибка или я плохо смотрю

(145) документ переделанный? есть обработки "колдовства" над табличной частью?? правила в последние дни документ??

пишу из под стола.... столько советчиков, что пи...ц


примари кей задвоен - это ошибка SQL, 1с тут совершенно не при чем

распростроненные варианты из-за чего это происходит
1. самый распространненный - SQL версии > 2000 и "криво" подруженый с 1с
2. дебилоиды бывают и в 1с (например изменение уровня изоляции блокировки, или кривые прямые запросы)
3. кривые индексы (как правило из-за совместного использования семерки и хрюши)


лечится поиском и дропом задвоеной записи.
Нокроме лечения нужно устранить причину

в студию

1. версия скуля
2. наличие приблуд прямых запросов
3. наличие файла "дружбы" семерки и хрюши

дроп задвоенное уже был, баянист))

зачем лечить, новую дешевле

(149) переделанный, в смысле, нетиповой?
в этом ТиСе работаю уже лет 7, если что-то и писали, то давным-давно...
правила документ в каком смысле? я их создавала и добавляла в готовые доки еще номенклатуру... больше ничего не делала... раз отрубилась сессия и семерка осталась включенной... возможно, что сервер вырубался, я туда не заходила пару дней... там еще другие люди на этом сервере работают в восьмерке

может мне ее выгрузить в дбф и там уже сделать этот май и июнь? а то меня бух съест))))

(150) Так у нее задвоенной уже нет - реиндексация прошла.

(156) реиндексация не исправляет задвоение...

(156) задвоений как таковых еще нет - скуль не пропускает. Просто уже есть левая запись с таким же ключем.


для начала стоило бы отловить на каком значении индекса вываливается ошибка. Если в логах этого значения нет, то стоит запустить профайлер и вызвать ошибку. в профайлере найти значение ключа и удалить эту запись из таблички (лучше перед этим проанализировать что за запись, и если "аналогичные").

(157) вывалится с ошибкой.

(158) вопрос - откуда взялась запсь с идом нового документа, или с идом сторого, но большим номером строки?

(158) примари кей генерится самим скулем, левой записи не может быть
(159) не всегда, попробуй создать две открытые транзакции с одинаковыми записями, результат будет зависить от уровня изоляции блокировок.

(161) странно - с какой стати скулю создавать первичный ключ??

(161) она одна работает, уровень не меняли. ТиС скорее всего, более чем стандартная.
а вот перевод на 2005-2008 я не исключаю.

(160) откуда ж я знаю...
факт в том, что при записи дока 1С сначала чистит табличку по каким-то условиям (скорее всего IDDOC=нужныйдок, но не по ключу), а после пытается записать новый набор данных и натыкает на записи с таким же ключем, которые теоретически должны были удалиться.

(162) "АвтоИнкрементация"

(165) вообще то, первичным ключом в 1С являлся собственно генерируемый гуид, а не автоикрементное поле скл....

(164) как раз по ключу чистит.

и, если бы ключ был автоинкрементным, ошибки дубля первичного ключа в принципе не могло быть, так как за ключом следил бы сиквел..

если бы админ был в штате, он бы за сервером следил - мало ли что, свободного места там изначально предполагалось
(0) а за ник ЛучшаяДевушка в СССР я тя уже люблю, всегда хотел такую

Шо еще не починили?

(0) Лечить руками. Правь табличку с дублями. Ну и заодно посмотреть профайлер - че там скуль делает. Ну и походу все таблички на дубли проверить, типа гулять так гулять.

А если доки и всю инфу тупо обработкой перенести в такую же базу, но новую и чистую, созданную из МДшника текущей, - взлетит? Или ошибка в новую перекочует?

Так грохается при записи или при перепроведении ?

Просто, если при записи, то может быть простая ситуация, когда в таблице уникальности ID-документа он слетел на несколько порядков назад (это бывает, когда запускаешь "кривые" прямые запросы для создания документа с заранее заданным ID), и получается, что в базе есть записи с указанным ID и когда мы создаём документ, то происходит наложение - особенно, когда был документ другого типа и в другой таблице - "умная" 1С просто оставляет ID и записывает новый документ в таблицы с указанным ID, но старый вытирает не везде, и, если он был проведён, то в записи проведения остаются записи с указанным ID-документа, но другим типом - как их удалить ?

индексацию и дефрагминтацию базы в самом sql

DBCC CHECKDB('DATABASE',REPAIR_ALLOW_DATA LOSS)

или на крайняк

такое раз в месяц делаю

USE  имя базы
DECLARE @MyTable varchar (32)
DECLARE @MyIndex varchar (32)
DECLARE MyCursor CURSOR FOR
SELECT o.name,i.name
FROM sysobjects o INNER JOIN sysindexes i ON o.id=i.id
WHERE (o.xtype='U') AND (INDEXPROPERTY(i.id,i.name,'isStatistics')=0)
AND (i.dpages>0)
ORDER BY o.name, i.indid
OPEN MyCursor
FETCH NEXT FROM MyCursor INTO @MyTable, @MyIndex
WHILE @@FETCH_STATUS=0
BEGIN
PRINT 'ДЕФРАГМЕНТАЦИЯ ИНДЕКСА'+@MyIndex+'из таблицы'+@MyTable
DBCC INDEXDEFRAG (0,@MyTable,@MyIndex)
FETCH NEXT FROM MyCursor INTO @MyTable, @MyIndex
END
CLOSE MyCursor
DEALLOCATE MyCursor

ну енто надо делать ессествено монопольно в  базе
sp_dboption 'имя базы','single user',true

о а скуль какой ? выше для 2000

(173) судя п овсему - при записи. При проведении dt не переписывается.
(174) Тут что-то более хитрое.
(176) сингл юзер для индексдефрага не нужен

встречал такой механим задвоение IDDOC

последний IDDOC грохается из общего журнала но остается в таблице документа, при создании нового документа 1с проверяет только общий журнал и разрешает создать документ.

соответственно мы в журнале имеем одну запись а в таблице документа две...

конечно сабж возникает при стечении определенных обстоятельст, у меня было (примерно 1 раз в квартал) при потери части пакетов на роуторе (после замены роутера все наладилось).

(179) Мы с ней вчера выполнили только

SELECT     IDDOC, LINENO_
FROM         DT782
GROUP BY IDDOC, LINENO_
HAVING      (COUNT(*) > 1)

показало 0 записей. и

DBCC DBREINDEX (DT782, PK_DT782)

Как проверить дубли ключей PK_DT782 я даже не знаю

(181) если вы реиндекс сделали, и он прошел без ошибок - то дублей нет.
(180) Так у нее грохается не на записи, а на ПЕРЕзаписи. Т.е. такое ощущение, что перед перезаписью ДТ не очищается.
вообще, надо профайлером трассу посмотреть бы. но как объяснить ТС "что такое профайлер и как с ним бороться" - я ХЕЗ.

(182) ей надо звать в гости "ЛучнийЮношаСССР",

а вообще я ей посоветую

1. скуле создать НОВУЮ базу (файлы указать на другой HDD)
2. сделать выгрузку из текущей средствами 1с
3. сделать загрузку в новую базу

этим решатся проблеммы кривой настройки базы или проблемм связаных с физическими причинами самого скулевского файла, и проблеммы мусора 1с в базе (например загрузка в ЗИК ТИС)


если не поможет - с другого компа поработать, и желательно даже с другой подсети, этим отсечем региональные настройки клиента и проблеммы с сетью в целом

можно будет

(183) Нелегко ставить диагноз по фотографии...а уж оперировать....

всем доброе утро

(183) >>если не поможет - с другого компа поработать, и желательно даже с другой подсети, этим отсечем региональные настройки клиента и проблемы с сетью в целом

я из дома работала позавчера, когда начала отваливаться, а вчера весь день из офиса... если я зайду под другим юзером на сервер, может это чем-то помочь?

еще вот вспомнила, что два дока Поступление товаров грузила пару недель назад обработкой внешней, для загрузки их екселя, раньше не пользовалась...
это все, что было новое в базе за последние лет 5

(181).2 вот сегодня снова экспериментирую

1.беру проведенный док, в который я вчера добавляла уже товар и он провелся с этим добавленный товаром
2.отменяю проведение
3.добавляю туда еще номенклатуру
4. жму ЗАПИСАТЬ (раньше жала Ок) и снова выдает ошибку

(185) не поможет

(186) 1.Это на любом документе ?
     2.А что происходит если не делать отмену поведения ?
     3.Номенклатуру добавляете последней строкой или нет ?
     4.Строки табличной части упорядочены с 1 по N без пропусков

(183) я бы в дбф давно выгрузил и работал на дбфной.

(186) Порядок действий в (80)

(190) причем тут проведение вообще? она интерактивно в документ элемент справочника вставить не может

(186)Вы бы лучше работали не с 1С, а со скулем ;)
По сути, даже руками можно поправить.
По ошибки в (0), он ясно ссылается на дубликат.

(191) Она упорно бьется об стекло, вот вот пробьет :)

(192) нету там дублей

я бы поглядел документы без даты

(194) У нее произошла частичная запись документа.
Надо найти ВСЕ ссылки на идентификатор данного документа и почистить их.

(195)все ссылки искать не имеет смысла. А вот посмотреть после записи все ссылки на строки - не мешало бы..

(188) 1.на любом документе, раз проводит, другой раз не проводит, раз записывает, второй раз нет
2.если не делать отмену, то же самое происходит, отменять я уже после стала
3.добавляю последней и упорядочиваю по алфавиту (попробую не упорядочивать)
4.тут не поняла ничего

(189) ну выгружу видимо, если так и будет продолжаться)

(190) скажите, что за чем сделать, чтобы по логам найти документ и в выгрузке его подчистить, я попробую... сама я не разберусь... если интересно вам, чем все это вылечить и когда это закончится))

(199) После упорядочивания у Вас получаются две строки
с одинаковым номером строки. Попробуйте сделать все тоже самое без упорядочивания.

Также скажите сколько строк в табличной части документов.

199 к 198

(199) строк от пяти до двадцати максимум

попробую понабивать без упорядочивания

+(201).2 хотя это неправильно, имхо... не должно ей так плохо становится при нормальной работе...

(202) А кто сказал что это правильно.
Это как бы единственное объяснение Вашей ситуации.

Скорее всего проблема в установке ключа. Есть конфликт. Попробуй прописать ключи,  мне кажется у тебя их не один. Т.е. один ключ должен использовать LPT - порт, а остальные COM-порт. Опять же проверь. Под SQL идут ключи, отличные от ключей DBF.

Опять же хороший способ исправить ошибку по ключу - послать запрос в 1С с описанием ошибки установки ключа.Есть в 1С прога тестирования правильности установки ключей.

Лечил такое, в ошибке есть вся необходимая инфа. Не удается создать Primary key, так как создаваемый ключ не уникален. Никакое ТИИ и всякие загрузки выгрузки не помогут! Нужно найти какому объекту 1С принадлежит строка таблицы и удалить этот объект (предварительно создав копию)!

(206) там только один класторный индекс

IDDOC, LINENO_

Смешная ветка... Кунсткамера какая-то...

я вот тоже первым делом бы выгрузил и залил бы все в дбфную чистенькую. Там бы посмотрел что и по чем - потом выгрузил из дбфки и залил бы в скульную - так 99% всякого бреда лечится обычно

причем не в DB а просто создал бы чистую конфу dbf ную и в нее лил бы.

(207) Если колонка IDDOC и есть Primary key, тогда в этой колонке значение PK_DT782 и есть ключ, который 1С пытается снова вставить в табличку!

+(211) осталось найти документ в 1С, который сделал эту запись и удалить его, сделав копию.

эх, еще бы понимать, на каком языке вы тут разговариваете:))

(211) щазз забаню

(213) лучше не понимай. а то один мат на языке...

(213) Если у Вас есть человек понимающий что такое профайлер то так как строк мало он легко найдет на какой строке (LINENO_)
все это происходит а после этого будет легче понять ситуацию.

(216) на данный момент я тут один "понимающий"))

ошибка, кстати, пока больше не появляется... сначала я перестала не упорядочивать номенклатуру, потом стала сначала записывать, потом упорядочивать, теперь уже несколько доков подряд сразу упорядочиваю по алфавиту, вроде не ругается...

если дальше буду работать и не будет выдавать ошибку, то можно не дергаться и работать в ней дальше или это сигнал, что она умрет в один волшебный день насовсем?

(217) MS SQL очень надежный - он не умрет. Главное делайте резервные копии ( каталог базы + копия базы sql).

Может  разные релизы 1с на разных компьютерах
или какие-то региональные настройки на Вашем компе
или нечто похожее было -  драйвер odbc был очень древнийший
на одном компьютере и отчет выдавал на этом компьютере неправильный результат.
так очень сложно сказать. Если это проявляется только на одном компе легче операц. систему переустановить чем искать причину.

Ошибка упорядочивания проявляется у Вас не всегда а на какой-то комбинации данных так что ошибка есть она просто не на всех документах  проявляется.

Епона мать
Спецы то, конечно, есть но прочитать буковки в картинке даже не смогли...

Когда-то давно было такое дело
Вообще 1С достаточно умная, без необходимости строки в документ не пишет "insert into DT..."
Продолжение тут:
http://www.1cpp.ru/forum/YaBB.pl?num=1201875913/44#44

Плохо в этом решении то, что 1С записывает заново всю табличную часть
Но зато никогда больше не было такой ошибки в заявке (только один такой проблемный документ был)
Индексации и прочие пляски мне лично не помогли

вести с полей))

ну я добила май - месяц, в котором набила заранее документы, а потом в них добавляла еще товар, больше ошибок не было...
будем надеется, что дальше ничего не выскочит...

вообще за 10 лет работы с семеркой она меня ни разу так не радовала, поэтому я собсно и не знала, что с ней в таких случаях делать... ничего, правда, после этой ветки не изменилось - я так же не знаю, что с ней делать, но было очень интересно... спасибо)

О сколько нам открытий чудных готовит наша Одинэс

(220) костыль какой-то

(222) а у тебя часом табличная часть в документе не больше 9999 строк?

(225) НЕ, у нее мало. просто она пересортировывает строки у записанного...

(222) Можете прогнать базу через мою обработку
"Поиск ошибок в регистрах 7.7" с инфостарта
может найдутся другие ошибки в данных.

(227) а регистры-то причем?

(228) он хочет эту ошибку пока оставить, и поискать другие :)

(229)"Никогда не выявляйте в программе ошибки, если не знаете, что с ними  делать дальше"© законы Мэрфи...

(228) ошибки могут быть и в регистрах.
а также название уже не соответсвует действительности
ищутся ошибки и по регистрам и по документам и справочникам

(224) Сергей какой-то...