Обновляю правленную базу бухгалтерии 568. Md готовился под ХР и семеркой, блоками, md с блоками правок сохранялись с текущей кодировкой семерки и ХР соответственно, потом объединялись под ХР. Полный md сохранен с текущей кодировкой ХР.
При объединении с md на копии боевой базы SQL дает ошибку "CREATE UNICUE INDEX terminated because a duplicate key was found for index ID 2.Most significant primary key is '1FUPQ '. SQL State: 01000.Native 3621... The statement has been terminated.".
Предполагаю, что проблема в неправильной кодировке, надо было с кодировкой "русский, белорусский и т.д." сохранять. Что можно сделать сейчас? Поможет ли накат этого md на боевой в пустой базе dbf с сохранением в русской кодировке?

кодировка тут ни причём. База кривая....

(0) Вынь 7 и 1С 7.7 + ХП... зверский коктельчик + SQL :))

Да вы мазохистка... :)

+(0) Можно попросту убить Файлик "OrdNoChk.prm", Оставить только XP и сервер 2003 32х или 64х :)
И все у вас получится :)

+ GComp-мом можно разархивировать MD файл и упаковать его обратно

+ >>> GComp-мом

Соответственно, только под Вин ХП

(3) 1. Где взять GComp? Я с ним дела не имела еще.
2. Где находится OrdNoChk.prm, с которым надо поступить неуважительно?)
3. Можно ли вообще пользовать 1Сину под 7-кой?) И объединять с ХР в каком-либо виде?) Моих знаний явно мало.

наверное - в режиме конфигуратора - администрирование кодовая страница не доступна ?
ЗЫ или перекодировать пустой каталог с МД тяжко?

(0) Начинать нужно с фотки в ЛК. Это магия!

Причем тут md?
ошибка - в базе.

+(8) ну, или в ДНК

(5) >>> Можно ли вообще пользовать 1Сину под 7-кой?

Можно, с бубном и танцами.
Нельзя пользоваться при этом SQL, оно не поддерживает старый формат :)
Еще хуже когда одновременно работают и ХП и Вин7
Файл "OrdNoChk.prm" ищи в каталоге БД :)

+(10) >><>оно не поддерживает старый формат

Старый формат, который нужен для работы 1С 7.7 :)

+ И где фото? В бикини... если можно :)

(6), (9) Падающего подтолкни? Не комильфо - я же с проблемой обратилась, причем к высококлассным профессионалам. Если чего-то не знаю - бить по лицу - метод решения?
(8) База вообще с причудами. Но надо искать решение же, а не констатировать факт.
(10) SQL-я база под ХР. И как все-таки правильно - удалить OrdNoChk.prm или(и)архив менять GCompом? Вообще, уже спасибо большое за ответы!)

(7) - Что есть ЛК?) И что за фото требуется?) Не (12) же).

(13) база английским-по-белому написала, где у нее ошибка...
a duplicate key was found for index ID 2.Most significant primary key is '1FUPQ '.

(15) Если бы я знала, как с этим справиться, сюда бы не писала. Зачем такой тон? Я ведь обращаюсь за помощью. Или Миста стала закрытым клубом ОТЦОВ? Тогда прошу прощения, что потревожила.

согласен с ораторами в (1), (8) и (9)

(14) ЛК видимо личная карточка
ЗЫ если база не большая то выгрузка загрузка - собственно
ЗЫЫ а ошибку искать - это таки надо понимать - чем ее править - в самом скуле или средствами 1Цы /нам в наследство база досталась изначально с ошибкой, правили вручную таблицу на скуле /

(17) Дай Бог, чтобы у Вас никогда не было проблем. И к Вам никогда не обращались бы в таком тоне.

(18) База достаточно большая, чтобы стандартной выгрузкой-загрузкой помочь нельзя было. SQL я знаю плохо. Правили ли когда-то таблицы SQL вручную, не знаю. Хорошо бы, если б ошибку можно было поправить средствами 1С.

(20) Для начала на копии ТИИ запустиь.
Не поможет - тогда уже руками.

(20) http://www.sql.ru/forum/732913/create-unique-index-terminated-because-a-duplicate-key-was-found-for-index-id

+(22) Это тебе ссылка для демострации, что лучше позвать специалиста.

(12) При всем уважении к ТС, не надо фоток в бикини :).

(0) ТС. Ошибка в SQL-базе. Лучше позвать специалиста.

(24) Согласен. Самое лучшее фото - без бикини!

(21) + надо понимать что если ТИИ не пройдет то искать придется ошибку руками (SQL-ем)
ЗЫ не все ошибки ТиИ может поправить

(24) (25) Вы чего тут орете? :) Человек, однако, уже 5 лет здесь. Так что с фоткой - раньше надо было выступать :))))))))

(19) Ты не обижайся ;) Тут традиция такая - перед особями женского пола, особи мужского пола показывают свои 22 см :))))

(27) Ок. Буду тихо. Раньше было нельзя. Щас точно фотка будет.
А я ничего не показываю - наоборот - прячу.
:)

(27) Ну вот, норм реакция пошла). Правда,  я тут не с особями пытаюсь общаться, а с их умом и знаниями). Порой получается). Кстати, ТС можно использовать и для чтения). В том числе мой). Это к вопросу о бикини). Чуть опоздали вы с предложениями). Я пугающую инфу, кажется, убрала, но намекаю - на этом свете живу далеко не 5 лет тут).
(24,26) Базу восстановлю, ТИИ прогоню. Если бред - буду звать спеца. Такое тоже бывало.
Всем спасибо большое, в том числе тем, кто сперва обидел, потом развлек!)

(29) Ты возможно не так накатила обновление.
Проблема возможно в том, что у измененной базы дубли, к примеру, кода, допустимы, а в типовой - нет. Возможно в изменена уникальность кодов ранее было в пределах справочника, в измененой - в пределах группы.
Рой тут.
Но фотку жду.

(27) Она страшная? :)

(31) Как SQL база?!
:)

(31) Не знаю.... Может наоборот - ослепляюще красива.

(33) Если ослепляюще, то тем более мир должен лицезреть эту красоту :)

(33) Как новый набор ключей для автомобиля?!

(29) есть работа с скулем стандартными средствами SQL
(бэкап БД обязательно)

http://www.1csql.ru/materials/faq/admin.html?pagenumber=2
http://mitkin.blogspot.ru/2011/07/ms-sql-server.html
http://sysadmins.ru/post7982416.html

(35) Не... как набор освежителя в салон :)

(16) А что вам не понравилось в тоне?
Вам просто было сказано, что программа сама вам пишет - где именно ошибка. и что md ни при чем.
(30) там первичный индекс строится, поэтому область уникальности кода тут ни при чем.

(29) Держи текстовичек хелпа по SQL

http://yadi.sk/d/2DSqEyuAE57iJ

+(29)Там сборник всех проблем и решений по 1С 7.7 на SQL :)

(38) Возможно. Но что-то инициировало перестройку этого индекса.

(35) Мда... Мужская логика.... :)))))))))))

Всем-всем-всем).
1. По делу: попробую выгрузку-загрузку. Если не поможет, попрошу спеца помочь с поиском задвоения в SQL - или чего-то, маскирующегося под задвоение). (36), (39) - спасибо за хелп! Посмотрю все обязательно).(38) - я понимаю, но не знаю пока, что делать). Начну с выгрузки-загрузки.
2. По жизни). Фото могу прислать только многолетней давности - оно устроило бы многих, возможно). Но не буду, ибо поезд ушел, и возвращать не стоит). Спасибо за улыбку).

(43) если база сильно большая , есть поделка от romix-а для выгрузке/загрузке больших БД

http://sysadmins.ru/post7588839.html

(44)romix-ом пользуюсь, но спасибо).

(43) Не поможет.

нашёл тут у себя краткое описание проблемы, но и это врядли поможет :)

Проблема такая: при обновлении конфигурации на этапе пересчёта перекрёстных ссылок 1С ругается
"CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2" и умирает.
Фишка в том, что она сначала напихивает записей в _1scrdoc, а потом уже создаёт уникальный индекс,
который не желает создаваться, т.к. 1С неправильно заполнила таблицу.
Не долго думая я залез в 1Cv7.DDS, нашёл там нужный индекс (CHILDID, MDID, PARENTVAL) и вырубил ему уникальность. После повторного запуска конфигуратора обновление завершилось прекрасно.
Далее, таким вот запросом
SELECT CHILDID, MDID, PARENTVAL, count(*)
FROM _1scrdoc
GROUP BY CHILDID, MDID, PARENTVAL
HAVING count(*) > 1
SELECT *
FROM _1sjourn
WHERE IDDoc IN (
    SELECT CHILDID
    FROM _1scrdoc
    GROUP BY CHILDID, MDID, PARENTVAL
    HAVING count(*) > 1
)
определил, какие документы так жестоко ввели 1С в заблуждение (это оказались выписки). Нашёл эти
документы в 1С и перепровёл. Удалил _1scrdoc, включил уникальность обратно, зашёл в 1С - всё зашибись,
всё уникально.
Вопрос: какого фига? Небольшое исследование показало следующее: в таблице проводок по этим выпискам в
поле DocLineNo везде стояло 0, и в поле Date_Time_DocID время было ни разу не такое, как в документе.
Но почему так получилось непонятно. После перепроведения всё стало нормально.

(46) Спасибо большое, идея хорошая. Я сейчас уже общаюсь с одним из ваших коллег, который мне помог в прошлом со SQL-ми проблемами в этой же базе, смотрит, что к чему, с обеда буду в офисе, займемся вплотную, пока по телефону). Когда что-то станет ясно, постараюсь написать, возможно, кому-то пригодится решение.

Итак, наши действия.
1. Стандартной процедурой _1sp_DBReindex из Stored Procedures проверили существующую базу на дубли индексов - не нашлось.
2. В DDS в _1scrdoc обнулили Unique у CHILD и PARENT, затем в таблице _1scrdoc отредактировали их же, убрав галочку в Unique values.
3. Запустили обновление правленной базы с 551 на 568 релиз моей болванкой md. Тот же вылет при создании таблицы индексов. Значит, дело не в 1scrdoc.
4. Создали в Enterprise Manager автоматический скрипт для поиска всей информации по индексам, рассчитывая либо в нем найти данные по недоделанным индексам, либо сделать еще одну копию базы, в ней такой же скрипт и сравнить тексты двух скриптов. Время у советчика вышло, завтра продолжим.

...  сначала напихивает записей в _1scrdoc, а потом уже создаёт уникальный индекс

эта ключевая фраза осталась, очевидно, непонятой

(49) Не осталась - см.пп.2 и 3. К сожалению, не помогло... Что лучше делать в таком случае, как считаете?

(49) Или не надо было в таблице _1scrdoc убирать галочку в Unique values? И что еще стоило сделать не так?

когда обновляется _1scrdoc происходит следующее:
- удаляется 1scrdoc. _совсем_удаляется_
- создаётся пустая _1scrdoc, без индксов
- наполняется записями
- создаются индексы

т.е. все манипуляции с _текущей_ 1scrdoc ни к чему не приведут, и ошибок там нет. Ошибка возникает именно в процессе обновления. И ДДС надо править не _перед_ накатом нового МДшника, а после того, как 1С издохнет. Поправить, и продолжить процесс обновления.

Кроме того, таблица возможно и не 1scrdoc  - но для выяснения этого факта есть например profiler.

(52) Принято к сведению. У меня просто нет знаний на этом уровне, а мой советчик сейчас болен, видно, пропустил эту информацию. В 9 позвоню ему и продолжим. Вопрос: исходя из проделанного, можно ли сейчас пойти по этой схеме, т.е поправить DDS и проверять дальше?

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

+(52) И не понимаю еще - стоит ли вручную удалить все из таблицы 1scrdoc перед продолжением или надо базу восстановить тестовую с нуля?

(54) Конечно, все делается на тестовой базе и весь Ваш текст я помню уже почти наизусть - в том числе о восстановлениии индексов в конце проверок).

(54) Ваша помощь очень важна, и информация неоценима!

(55) без разницы, она же заново сгенерируется

Все поняла! Сейчас попробую DDS поправить и запустить обновление снова.

(58) После правки DDSа обновление прошло!) Ваш запрос выдал пустую табличку, т.е. повторов вроде как нет?! Непонятно тогда, что это было).
Теперь удалять _1scrdoc? Что, саму таблицу удалять, в SQL?

(46) время поди 23:59:59 было, да ?
:)

(60) да, можешь её грохнуть и сделать ТиИ (с одной галкой) - восстановится

(61) Время вполне такое могло быть). Удаляю табличку _1scrdoc.

(63) Я не у вас , а у Алексея спрашивал, хотя, у вас такие записи тоже имеют место быть.

(61) Кстати, все время об это время спотыкаюсь). Чем оно чревато, толком объясните нубочке?) Нигде внятного ответа не нашла - от ничем до незнамо чем только)

(65) невозможность записать много документов в пределах одной секунды в  23:59:59, после некоего числа, время в проводках и операциях становится другим, чем в 1sjourn .. из-за этого траблы

грубо позиция одного документа в этих табличках отличается.
Лечить в скуле, можно тупо тригер навесить, к примеру.

ну вот, например
http://www.1cpp.ru/forum/YaBB.pl?num=1281425103/8#8

(61) Это было очень давно, не помню. Но скорее всего оно, родимое.

(66), (69) Ребята, получилось!!!) Время в доках придется программно исправить). (68) Посмотрю сейчас).

ВСЕМ СПАСИБО ОГРОМНОЕ!!!!!))) И замечательного дня!)

Ребята, последнее. Мне мой советчик сказал, что в 1 секунду все-таки ограниченное количество доков загнать можно - и не только в 23:59:59. Вроде как то ли тысячу, то ли 10 000... Что скажете, умный народ?)

У нас просто в эту базу выгрузка идет из многих источников, и кое-где есть программное распределение доков по периодам дня. Надо знать точные ограничения...

В ссылке из (68), кстати, следующее:

Итак, причины:
Причина ровно одна - запись нового документа в режиме "в конец дня" при наличии в этом дне документов со временем >= 23:59:50. (в посте по ссылке я немного неверно написал - при изменении времени существующих ошибка не наблюдается).
С "большим количеством документов в 23:59:59" никак не связано. Достаточно одного, и даже чуть раньше, чем 59:59.
Операция нового документа получает время последний_документ_в_дне + 10 секунд (т.е. от 23:60:00 до 23:60:09)
Ошибка возникает в таблице _1SOper и дальше мигрирует по остальным таблицам бух. подсистемы.

(71) загнать можно - проблема с разной позицией будет + сообщение об ошибке - о невозможности провести документ за ТА..

(74) Так есть разумные ограничения - или все свше 1 док в сек чревато?)

(71) Лучше так не делай. Документы лучше расфасовать на весь день. Обработкой конечно.
А так, если любят писать вчерашним числом, то лучше всегда ставить текущее время. И проблема исчезнет :)

(75) Есть ограничения на 23:59:59.

(76),(77) Беда в (72). Для бухов безразлично распределение по времени в дне, строго говоря, но доков базе много на день приходится, а на 8-ку только в будущем году перейдем летом. Попробую все приходящее при загрузке раскидывать посекундно, но не уверена, что помещу.

А сейчас еще проблема возникла - день в обновленной базе отработали бухи и обнаружили, что разрушилась связь между документами-основаниями и счетами-фактурами на их основании.
В счете-фактуре основанием указана Отгрузка товаров, продукции, по кнопке "О" открывается, т.е рекв.ДокументОснование в порядке. Лезу в Отгрузку - журнал подчиненных документов пуст. Еще фокус: в доке ЗаписьКнигиПокупок в поле Основание - Счет-фактура. Документ-основание-Выгрузка. Это уже фокусы нестандартной обработки загрузки из другой базы. Пытаюсь по кнопке с "..." открыть основание - вываливается пустой журнал счетов-фактур. Отдельно он открывается нормально, счета-фактуры на месте.
Что делать?

прибить 1crcdoc сделать тии

с одной галкой

(80),(81) Я при загрузке делала же так. Повторить? И прибить - это удалить и сделать Тии с одной галкой, восстановив индексы?

нет.. если дбф - удалить файл, если скуль - truncate table
далее в Тии , галка пересчет служ. данных.

Скуль. Что такое truncate table и как это сделать в Enterprise manager? -  я в скуле почти нуль.

(84) для (83)

(84)
http://yandex.ru/yandsearch?clid=9582&text=truncate+table+ms+sql&lr=213

http://images.yandex.ru/yandsearch?source=psearch&text=Enterprise%20manager%20ms%20sql&fp=0&pos=0&rpt=simage&lr=213&uinfo=ww-1390-wh-734-fw-1165-fh-528-pd-1&img_url=http%3A%2F%2Fwww.quackit.com%2Fpix%2Fdatabase%2Ftutorial%2Fdbms_sql_server.gif

(84) сделай копию, затем в QA выполни
TRUNCATE TABLE dbo._1SCRDOC
усё..

(86) 2-я и 4-я ссылки не читаются, и разбирать сейчас поздно, мне бы точные пошанговые инструкции на этот раз. Понимаю, что с моей стороны нехорошо это просить, но деваться мне некуда. Обязуюсь после завершения этой истории все внимательно прочитать!)
(84) Сделаю, потом напишу, что получилось.

(84),(86) Так. Копию базы мне сделали, могу работать. Теперь : стоит ли мне перед началом TRUNCATE прогнать обработку по изменению времени доков, которые в 23:59:50-23:59:59, на, скажем, 23:59:49? Или опять будут проблемы? Таких документов очень много.

+(89) Или надо распределить все доки по секундам, а, если секунд не хватит, хвост на 23:59:49? Но я не могу трогать закрытые периоды, а база с начала 2012 года... Перепроводить не могу. А кривизна операций и проводок ведь при проведении?

(+89) Я про кривизну времени.

(90) можно в скуле проапдейтить табличку, чтоб позиция дока была такой же, как  в _1sjourn

(92) Как я поняла, придется менять время документов, операций и проводок в закрытых периодах.
Можно ли при этом обойтись без перепроведения, чтобы не посыпались данные в закрытых периодах? Какие таблички в SQL при этом и как стоит поменять, причем так, чтобы не посыпался 1С?

(93) _1sentry/_1soper + файло итогов пересчитать потом

Вот, нашёл тут :)


///******************************** ADirks 03.10.2013 ************
Функция сзТаблицы()
    сз = СоздатьОбъект("СписокЗначений");
    сз.ДобавитьЗначение("_1SACCSEL");
    сз.ДобавитьЗначение("_1SENTRY");
    сз.ДобавитьЗначение("_1SOPER");
    сз.ДобавитьЗначение("_1SSBSEL");
    Возврат сз;
КонецФункции

Функция тзПроводки()
    ТекстЗапроса = "Set NoCount ON
    |
    |-- Время проводки не совпадает с временем документа
    |
    |select
    |    Right(_1sJourn.Date_Time_IDDoc, 13) [Doc $Документ],
    |    _1sjourn.IdDocDef,
    |    _1sjourn.IDDoc,
    |    _1sjourn.DocNo,
    |    _1sjourn.Date_Time_IDDoc,
    |    _1sentry.Date_Time_DocID,
    |    count(*)
    |from
    |    _1sjourn (nolock)
    |    INNER JOIN _1sentry (nolock) ON (_1sjourn.IDDoc = _1sentry.DocID)
    |where
    |    _1sjourn.Date_Time_IDDoc <> _1sentry.Date_Time_DocID
    |GROUP BY
    |    _1sjourn.Date_Time_IDDoc,
    |    _1sentry.Date_Time_DocID,
    |--    Right(_1sJourn.Date_Time_IDDoc, 13),
    |    _1sjourn.IdDocDef,
    |    _1sjourn.IDDoc,
    |    _1sjourn.DocNo
    |";
    тз = ЗапросСКЛ.ВыполнитьИнструкцию(ТекстЗапроса);
    Возврат тз;
КонецФункции

Функция тзТаб(Имя)
    ТекстЗапроса = "Set NoCount ON
    |
    |-- Время проводки не совпадает с временем документа
    |
    |select
    |    Right(_1sJourn.Date_Time_IDDoc, 13) [Doc $Документ],
    |    _1sjourn.IdDocDef,
    |    _1sjourn.IDDoc,
    |    _1sjourn.DocNo,
    |    _1sjourn.Date_Time_IDDoc,
    |    "+Имя+".Date_Time_DocID,
    |    count(*)
    |from
    |    _1sjourn (nolock)
    |    INNER JOIN "+Имя+" (nolock) ON (_1sjourn.IDDoc = "+Имя+".DocID)
    |where
    |    _1sjourn.Date_Time_IDDoc <> "+Имя+".Date_Time_DocID
    |GROUP BY
    |    _1sjourn.Date_Time_IDDoc,
    |    "+Имя+".Date_Time_DocID,
    |--    Right(_1sJourn.Date_Time_IDDoc, 13),
    |    _1sjourn.IdDocDef,
    |    _1sjourn.IDDoc,
    |    _1sjourn.DocNo
    |";
    тз = ЗапросСКЛ.ВыполнитьИнструкцию(ТекстЗапроса);
    Возврат тз;
КонецФункции

///******************************** ADirks 03.10.2013 ************
Процедура Показать()
    сз = сзТаблицы();
    Для н = 1 По сз.РазмерСписка() Цикл
        Имя = сз.ПолучитьЗначение(н);
        тз = тзТаб(Имя);
        тз.Сортировать("Doc", 1);
        РедакторТЗ(тз, Имя);
    КонецЦикла;
    //
    //тз = тзПроводки();
    //тз.Сортировать("Doc", 1);
    //РедакторТЗ(тз);
КонецПроцедуры

Процедура Выправить()
    сз = сзТаблицы();
    Для н = 1 По сз.РазмерСписка() Цикл
        Имя = сз.ПолучитьЗначение(н);
        тз = тзТаб(Имя);
        РедакторТЗ(тз, Имя);

        тз.ВыбратьСтроки();
        Пока тз.ПолучитьСтроку() = 1 Цикл
            ЗапросСКЛ.Выполнить("Set NoCount ON
            |UPDATE "+Имя+"
            |    Set Date_Time_DocID = '"+тз.Date_Time_IDDoc+"'
            |WHERE
            |    DocID = '"+тз.IDDoc+"'
            |");
        КонецЦикла;
    КонецЦикла;
КонецПроцедуры

(95) ну, тесты проверок, в своё время кто тока не писал :))
В одну кучку Z1 собирал.. в своё время
на 1cpp валяются

чорт, не заметил про update внизу
..

Мне быстрее написать, чем найти готовое :)

(94), (95) Ребята, милые вы мои, дорогие, спасибо огромное за помощь!) Сейчас посмотрю тексты процедурок).
Только закончила вразумлять бухов).

(98) А Вам мне просто в ножки поклониться надо!) Как это ни выглядит смешным сегодня - но хочется!)

(95) 1. Что за РедакторТЗ(тз, Имя)? Не наблюден.
2. При просмотре наискось показалось, что время документа правится по времени операции. Для ситуации с 23:59:50+ операции записаны на незнамо когда. Надо бы наоборот - операцию к документу привязать)... Возможно ли это?) Естественно, документы перед этим поднять на пораньше, причем их надо записать, но не перепроводить - в закрытых периодах...

РедакторТЗ() - человеческая замена для тз.ВыбратьСтроку()
можно произвести обратную замену

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

(102)Ага, значит, можно и в операциях менять?) Уррряяяя!) А то ж закрытые же ж периоды же ж)... Через полчасика возьмусь).

(102) А это все можно делать под сервером скульным 2000?) Я так поняла, что да?)

Ну да, можно операции, и для SQL.
Собственно, это боевая обработка, коей мы обнаруженный косяк правили.

(105) А что за ЗапросСКЛ и ВыполнитьИнструкцию?

(106)
В яндексе забанили?
http://yandex.ru/yandsearch?text=ВыполнитьИнструкцию+1с&lr=213

(107) Хорошо, неправа насчет ВыполнитьИнструкцию. А как определить ЗапросСКЛ? Код ругается. В гугле  про запрос СКД только вижу. Ругай, переживу, только поверни в нужнгую сторону. Это же не 1Совский запрос.

(108) И, потом, ВыполнитьИнструкцию - это 1С++? У меня не установлен.

(108)
ЗапросСКЛ = СоздатьОбъект("ODBCRecordSet");

(109)
ЗагрузитьВнешнююКомпоненту("1cpp.dll") воткни перед этим

(108)

Вам привели пример. Ваша задача адаптировать его.
соответственно пример написан на чистом tsql.
и для его исполнения достаточно иметь ms SQL Query Analyzer
либо любой другой инструмент, позволяющий исполнять запросы.

(110),(111) Вот это другое дело). Сделаю).
(112) И так попробую.

Ребята, простите, что так надолго замолчала.  Начальник уходил в отпуск, и, раз сразу не получилось, не стал рисковать и вернул базу, в которой ваяли сутки, на место. Мне пришлось разбираться и восстанавливать информацию.
Теперь пора заняться основной темой).Я посмотрела код в 95, и вижу, что им можно воспользоваться напрямую, спасибо огромное! Но есть один вопрос: поскольку много доков на 23:59:59, то не стоит ли прежде прибивания операций и проводок к ним поменять их время? И можно ли это сделать прямо в 1Се для закрытых периодов - т.е.перезаписать с другим временем без перепроведения и потом прибить к ним все SQLем?
Или, учитывая кривость таблиц, лучше все сделать SQLем? Если да, то как поменять им время? Не скажется ли UPDATE таблиц из сзТаблицы() еще на чем-то 1Свском? Потому что сделать запрос по образцу я смогу, а вот дальше боязно)...

(114) проапдейтить таблички.. это фигня.. тебе придётся потом бух итоги пересчитать.

на счет исправления времени в табличках проводок - вам Алексей постами выше дал рабочий код..

Итоги все же в 1Се пересчитывать). А вот что можно и нужно апдейтить-вот вопрос). Хотя)... В прошедших-то периодах отчеты сданы)... А итоги пересчитывались несколько месяцев назад)... Что, по-любому плёхо, однако?)

По мне, я бы исправил всё и пересчитал всё.

(116) Я про код написала-код замечательный). Но он для прибивания операций и проводок к докумен6там, а мне прежде время доков менять надо). Об этом и страх)

(118) Конечно, все до ума доводить надо). Вопрос - время доков из 1Са менять или все сделать SQLно, добавив в код про сдвиг доков?

И потом пересчитать итоги...

Ребята, я все перечитала, мне помогают с написанием процедур на SQL, но, все-таки не все понимаю еще. Базу вернули в исходное состояние, до обновления. Сейчас мне надо сперва обновить - попасть на ошибку - убрать уникальность в DDSе - закончить обновление - удалить _1scrdoc  - сделать ТИИ с 1 галкой - включить уникальность обратно (или сперва включить уникальность, а потом ТИИ?, или TRUNCATE TABLE dbo._1SCRDOC и далее в Тии , галка пересчет служ. данных?). И потом SQL-й процедурой подтянуть время документов в 1sjourn, а потом к ним привязать _1SACCSEL, _1SENTRY, _1SOPER, _1SSBSEL? В середине путаюсь, про обновление. Помогите еще раз, очень прошу!

(122)+ Или вообще сперва наладить время документов, а уж потом обновлять?

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

(124) Скрипт из (95)? До обновления? Или все же сперва обновить-ошибка-убрать уник.-законичть обновление-TRUNCATE TABLE dbo._1SCRDOC-пересчет служ.данных?
А насчет времени остальных доков не все так просто. Если связь доков с операциями и проводками разорвана из-за того, что из в 23:59:59 в какие-то даты собралось слишком много, скажем, больше 10000, то в новых доках, формирующих проводки, и записанных в эти даты, опять разорвутся связи с проводками и операциями. Поэтому и хочу поднять их с 01:00:00, как в одном месте рекомендовалось. Причем делать это придется скульно, чтобы не перепроводить доки в закрытых периодах. А потом то ли пересчитывать итоги, то ли они встанут на место при пересчете служебных данных - тоже хочу уточнить... Ведь доки буду поднимать в том же порядке и в пределах той же даты, так что итоги не должны полететь как бы?

Ага, из (95), до обновления. Все те манипуляции с уникальностью индекса на самом деле были проделаны, чтобы быстренько обновиться, а потом уж разбираться. Если исправить ситуацию до, то во время обновления проблем уже не будет.

Что касается дофига документов в одно время, то мы, например, на это начхали, просто сделали триггер, правящий ситуацию в момент записи (где-то ранее была ссылка на эту тему на 1cpp.ru). Можно и без триггеров, перед обновлением каждый раз скриптом время в операциях править.

(126) А без обновления этот разрыв нам нервы трепать не будет? На итоги это не повлияет?

(127)+ Триггер этот я видела. Но у нас не стоит 1Срр, и ставить ее я не рискую - малейший сбой, и меня убьют тумбочкой. Поэтому готова только на разовые правки, пусть и перед каждым обновлением). Недолго мучиться  - следующим летом, наконец, переводим все на восьмерку)

(126) И еще: то, что проблема с разрывом связей между счетами-фактурами и ЗаписьюКнигиПокупок однозначно отсюда - ясно, а вот такая фигня еще? обнаружили бухи, что  у некоторых контрагентов в Выписках не тот договор оказался. Причем во всех. Может ли это тоже быть из той же кашки?

(127) В том то и дело, что ни на какие итоги не влияет. Я, честно говоря, сильно удивился, когда стали смотреть что к чему, и выяснили, что документов с одинаковым временем - до чёрта. Т.е. прям полностью идентичные части Date_Time в Date_Time_IDDoc.

(129) насчёт разрывов я бы не был так уверен - там время вроде ни при чём. Что касается договоров, так это достаточно распространённая ситуация, связанная с кривизной ручек 1Снегов из 1С.

(130) Насчет разрывов, как мне кажется - дело в нарушении связей как раз между документами-основаниями и подчиненными, т.е. в нашей любимой табличке, нет? Этого до обновления ведь не было...
А вот с договорами что делать мне, бедной?) Убьют ведь, а Новый Год на носу)...

Ну так то да, если _1scrdoc криво заполнилась, то ВыбратьПодчиненныеДокументы() тоже будет криво работать. Но тут ничего не могу сказать, лечение по фотографии не мой профиль.
С договорами вообще сложно. Надо прям с каждой конкретной ситуацией разбираться. Причём вопрос из чисто технического становится организационно/бухгалтерским.

(132) Пока пришью операции  и проводки, обновлю, а там посмотрим по месту). Значит, итоги при таком раскладе не трогаем?) Ура!)

(132) Для начала - очередное огромное спасибо!)

Ну там, ура не ура, а попробовать надо. Время, судя по всему, есть :)

(135) Дошли до дела, наконец-то). Написана процедурка в SQL, которая прибивает время в _SACCSEL,_1SENTRY,_1SOPER,_1SSBSEL по _1sJourn.
Стало ясно, что после обновления бухи начнут править и создавать новые документы в прошлых датах, где все прибито будет, но время 23:59:50+ у доков останется, и мы опять получим тот же компот. Посмотрела триггер из (68). В нем по событию такому правится только _1SOPER, причем время, если оно бредово, заменяется на 23:59:59, как я поняла...
Вопросы: 1) Надо ли править остальные 3 таблички аналогично или, по (73), ошибка возникает в _1SOPER и потом мигрирует по остальным таблицам? В какой момент мигрирует тогда? После отработки триггера? 2) Не повлияет ли это действо еще на какие-то вещи в базе? На таблицы, вроде, нет, я просмотрела DDS... 3) Что делать с _1scrdoc и когда? Удалять, TRUNCATE? Мозги окончательно всмятку.

(136) Еще момент: база была обрезана, т.е. были на начало 2012 года созданы начальные остатки, а все старье помечено на удаление. Сейчас в _1sJourn моей помощницей в SQL обнаружено в 2011, помеченном на удаление, году, у ряда документов бредовое время - больше 23:59:59 в 36-ричной системе. Те годы не волнуют, но возможно ли повторение такого в текущих годах? Если да, то стоит ли повесить триггер аналогичный и на _1sJourn? Если да, то скажется ли это сильно на производительности?
Ради подробного ответа согласна на любые сомнения в качестве моей ДНК!)

(137)
на сколько больше ?

(138) Вопрос непонятен.

(139)

на сколько  сенкунд (10 тысячных секунды) больше
чем   23:59:59 в 36-ричной системе

вполне возможно, что это время в пределах 1 секунды

(140) Сейчас посмотрим.

Вот что найдено:
полный день в долях секунд = 864000000
В _1SACCSEL
имеем EAGG40 =     864090000. Полностью строка:
5562356    518       3Z2            15T2D       20120531EAGG40 15T2D       0    0

В _1sJourn:
1154418    45264      OWJ3       45164    20    20110111WKESG   OWJ3            451642011        07-0000015              4    1    0    4
int=1969200000
Дальше коммент программиста SQL:
Возможно, в 11 году по-другому считывалось время
20110111WKESG, и по новым правилам должно быть написано так:
20110111 WKESG  
тогда это не ошибка.
Мой коммент: 1Са она не знает, сишник.

(140) Ответ в (141). Но писала вслед за сишником, второпях. Вижу, что ее коммент не в тему, главное, что время бредовое есть и в _1sJourn/

(143)

что скажет РазобратьПозициюДокумента("20120531EAGG40 15T2D",Дата, Час, Мин , Сек, Документ) ?

(144) Прости, что не сразу отвечаю - переключилась на подготвку болванки 570 релиза.
Код:
    //Перем ДатаДока, Ч, М , С, Док;  
    
    ДатаДока='01.01.01'; Ч="";М="";С=""; Док=ПолучитьПустоеЗначение("Документ");
    
    Позиц=РазобратьПозициюДокумента("20120531EAGG40 15T2D",ДатаДока, Ч, М , С, Док);
    Сообщить("Позиция = "+Позиц+"; ДатаДокумента = "+ДатаДока+"; Ч = "+Ч+"; М = "+М+"; С = "+С
            +"; Документ = "+Док);
Ответ:
Позиция =   .  .   00:00:00; ДатаДокумента =   .  .  ; Ч = 0; М = 0; С = 0; Документ =
Одинаково - через Перем или явно нач.значения задавать.

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

(136) насчёт триггера, вроде же Паша всё расписал в той теме на 1cpp?
В том то и прикол, что для доков с операциями date_time_iddoc берётся из _1soper, а вовсе не из _1sjourn. Это "немного странно", но факт. Именно поэтому триггер и навесили на _1soper - достаточно там исправить, дальше само разойдётся.
Насчёт crdoc ничего сказать не могу - не исследовали за ненадобностью.

(147) Т.е. время формируется в _1SOPER при записи документа, триггером правится, и при проведении остальные таблички цепляются за _1SOPER? И почему в _1SOPER ставим триггером время не такое, как в журнале, а просто конец дня?
И насчёт crdoc - мне неясно, как с ней быть - там есть дата и время подчиненных доков. Если я перед обновлением прибью все существующее к _1sjourn по 4 табличкам, что, сразу обновление запускать, и crdoc просто пересчитается? А итоги надо пересчитывать после приколачивания или после обновления? Или при таком раскладе все и так будет замечательно?)

(147)+ Прошу прощения за занудство - слишком многое на кону, это наша основная база, а сейчас пора отчетности. Я, конечно, тестю, но все проверить невозможно же... А база и так еле жива - например, в конце декабря вдруг в Выписках в текущем, старом релизе бухи не смогли выбирать субконто... Я еще не смотрела, в чем дело, тоже отдохнуть решила в каникулы, сегодня взялась за все).

(147)+ Еще раз перечитала все, вроде правильно понимаю?). Для верности пишу еще раз). 1. Меняю время в 4 табличках по _1sjourn. 2. Вешаю триггер на _1SOPER. 3. Обновляю. 4. Пересчитываю итоги. Все правильно?)

(150) Почти так. Триггер лучше вешать после обновления, потому что 1С может его и прибить (не проверял, у нас все триггера тупо пересоздаются после каждого обновления).
Что касается crdoc, то попробую завтра посмотреть, чего там происходит.

(150)+ Напрягло бредовое время в (142) - и в помеченном на удаление 2011 году в _1sJourn, и в рабочем 2012 году в _1SACCSEL. Ну ладно, во втором случае оторвалось все, а в журнале? Как 1С обрабатывает пометку на удаление в документах? База обрезана, все до 2012 года помечено на удаление, я писала в (137). Что делать, если бред со временем в журнале? База бухгалтерская, вроде как не очень важно, что когда в течение суток, но все же они ручками всегда переставляют приходы прежде расходов...
(151) Жду про crdoс - и заранее благодарна за любую инфу, вообще Вы меня капитально выручили уже, Алексей, спасибо! Очень большое!

(151) Пост (152) адресован Вам). Ошиблась).

Как ни странно, в crdoc всё пучком пишется, даже и без всяких триггеров. Башню сносит только при перезаполнении.

ё..
порабы было ужо давно забить на эту базу
:))

(154) А что Вы думаете про бредовое время в помеченных на удаление доках в _1sJourn?
(155) Это как?) Дело не доделано, есть вопросы, знания я получаю только в этой ветке нужные. Да, медленно, прошу прощения. Но, будь я корифеем, вопросов и не было бы). В любом случае, спасибо за советы!) В этот раз очень помог Алексей, в другие разы Вы давали замечательные советы, за что я очень благодарна!) А сколько мне помог Михаил, это вообще слов нет... Спасибо вам, дорогие, что не плюете на нас с высокой1 горки своих знаний и умений!) Теперь, порой, по мелочи, и я кому-то помогаю)...

>А что Вы думаете про бредовое время в помеченных на удаление доках в _1sJourn?

я бы оставил как есть

(157) Еще раз о прошлых годах. До 2012 года все доки в базе помечены на удаление или сделаны непроведенными. В 4 табличках вся инфа по ним есть, но, насколько я понимаю, невидима для 1С. Вижу, что при изменениях в доке (проведен-непроведен-помечен на удаление) время в табличке журнала не меняется.
Вопрос: прибивать ли время к журналу в 4 табличках и за те годы? Не повлияет ли это на что-то? Насколько я поняла, нет и можно сплошь таблички прибивать?
И как быть, если в журнале время бредовое? Это только в прошлые годы бывало. Его подправлять на конец дня - все равно непроведенные доки?

(157)+ Понимаю, что надо по-любому за весь период все прибивать, иначе таблица ссылок при обновлении сыпанется. Вопрос, что делать, если в журнале время бредовое? То ли брать в этом случае за основу время из таблицы операций, а, если и там бред - в конец дня, то ли все в конец дня? Насколько я поняла, такое бывало только в ненужных годах...

(158)можешь вообще прибить эти доки.. насовсем, если ссылок по ним нигде нет.

+159 в табличке операций.. нет строчек с доками, помеченными на удалени или не проведенными.

(161) там нет, а в табличках проводок и т.д. есть, потому и спросила.
(160) Да, это обязательно сделаю.

(160)+ Кстати, ссылки в скле где смотреть - в crdoc? Или где-то еще? А то через 1С долго искать.

(163) например
http://infostart.ru/public/60727/

(164) Чего-то не пускает, пароль, видно, забыла. А можно сюда линкануть?)

http://rusfolder.com/39429750

(166) И тут требует авторизации, или не читает. Попробую дома вечером из Оперы, что-то тут Эксплорер барахлит к тому же). В любом случае, спасибо большое!) Прошу прощения, что не сразу отвечаю - болванку готовила для обновления на 570).

теперь ждем мучений по работе с 1с++...

и еще через месяц-другой (постов 300)

... увольнения

(168) Ты о чем? С 1С++ работать мне нельзя в этой базе, поэтому все процедуры написаны в SQL. Если все сработает, все нормально. А если нет, и даже если меня уволят, что маловероятно, то зачем так?

(169)
стеб по поводу количества времени и постов этой ветки.

+ (170)
кстати сегодня месяц, как создана тема

(170) И что? И зачем стеб? Жаль.

(172)

"Жаль" не сотвествует (108)

(173) Соответствует, но не теме ветки, а другой теме. Но об этом я больше не пишу.

Ребята, существенно ли по каким-либо параметрам, где делать пересчет итогов - в режиме Предприятия или в Конфигураторе?

На тестовой базе все обновилось, осталось итоги пересчитать и добавить триггер). Всем помогавшим спасибо огромное!) Ну и надо проверить, конечно, не вылезет ли еще какая-нибудь бяка). Дай Бог, чтобы все прошло благополучно).

И еще: нашла ссылку еще с 2009 года, что под 25 релизом -  а у нас именно он - полный пересчет итогов может глючить под 25 платформой, а у нас именно она, и в любом случае, работает очень медленно. И что есть некая процедура чисто SQL-я, которая может быстро итоги пересчитать. Есть ли у кого-то информация по этому поводу?
Сразу - 27 релиз предлагала поставить 100 лет назад, но из-за сложностей работы с удаленными базами на это не пошло мое начальство. Теперь уже важно все добить и с весны начать все переводить на восьмерку.
И еще: Я обновила, но переиндексацию не делала, сразу запустила полный пересчет итогов в режиме Предприятия. А сейчас думаю - может, надо было сперва восстановить crdoc? И вообще итоги считать в Конфигураторе или найти быструю и более верную скульную процедуру?

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

(178) Я тоже так думала, но... последние посты см. (150), (151). И до того было.

вот загатовка для обработки пересчета би
http://softpoint.ru/article_id46.htm

(179)
" пересчет служ. данных" <> "пересчет БИ"

"И до того было" -  про пересчет пересчет БИ не было советов.

(181): (94), (115), (117), (118), (150)-(151).
Но, кстати, итоги пересчиталлись аккуратно, с боевой базой совпадают.

(181)+ А вот насчет пересчета служебных данных не было речи, если 4 таблички (операции и проводки со всеми связями) прибиваются к журналу.

(182)
хорошо. совет про пересчет БИ был.

Для пересчета итогов по регистрам, и двиганья ТА в НЕмонопольном режиме есть такая штука: УстановкаТА, исходный вариант здесь: http://www.dev.citykirov.ru/

её потом кто-то допиливал, на предмет (кажется) оборотных регистров, и измерений с типом Неопеределено где качать найти теперь не могу, положил на http://rusfolder.com/39432040

(185)

для пересчета регистров есть обработки на 1cpp и infostart

а вот для БИ - не встречал.

(185), (186) Я их нашла, там и про БИ что-то есть, но, не разобрав, и не проверив, использовать пока не рискую. Запустила обычный пересчет в режиме Предприятия. Долгий он, правда...

Все завершено, триггер на месте. Утром бухи начнут работать, станет ясно, как у них дела. Ушла отдохнуть до утра)...

(185) Спасипки

Ну вот, вроде все ОК). Всем огромное спасибо за помощь!) Чтоб у вас все всегда получалось, ребята!!!)

(190) более правильно этот тост надо говорить так:

"дай бог вам между ног крепкого здоровья!"