Эх... МоментВремени() !

27.04.11

Два документа записаны с одинаковой датой . Какой из документов будет левее (раньше) на временной оси ?

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		Бесплатно
СравнениеМоментовВремени82.epf .epf 6,15Kb 123	123	Скачать бесплатно

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

Если рассматриваемые документы имеют различный тип , то однозначно ответить на поставленный вопрос невозможно.
Пример для конфигурации БП2.0.

Другими словами, в БП 2.0 типовой документ "КорректировкаДолга" созданный в последнюю секунду месяца при проведении никогда не учтет долг по документу "РеализацияТоваровУслуг" с той же "датой-временем". В этом эффекте можно убедиться практическим путем.

Эта особенность в выстраивании последовательности документов по моменту времени явно описана
на сайте http://www.lavelin.ru/index.php/article/1c/54-razrabotka/103-moment-vremeni-i-granica-naznachenie-primery-ispolzovaniya

Момент времени:
Фирма 1С описывает так:
Предназначен для получения и хранения момента времени для объекта в базе данных. Содержит дату и время, а также ссылку на объект базы данных. Используется в качестве значений свойств и параметров методов других объектов, имеющих тип МоментВремени.
Момент времени используется в тех случаях, когда важно различать моменты времени для объектов, имеющих одинаковую дату и время, например для сравнения положений документов на временной оси.
А своими словами:
Момент времени - комбинация даты и ссылки на документ. Позволяет разделить и упорядочить документы в пределах одной секунды, выстраивая все документы в однозначную последовательность. Получение данных при проведении на момент времени гарантирует, что будут учтены движения сделанные в ту же секунду что и проводимый документ, но находящиеся перед ним.
Но есть особенность - документы проведенные в одну и ту же секунду располагаются в произвольном порядке, а не в порядке их физического создания (как было в 7.7).

Последнее выделенное автором предложение , правда, требует уточнения.
На мой взгляд, правильно так :
"Но есть особенность - документы разного типа , записанные в одну и ту же секунду, располагаются в произвольном порядке, а не в порядке их физического создания (как было в 7.7). Документы же одного типа располагаются в порядке их физического создания."

1. Первый посткриптум к статье.

После того как статья была опубликована пользователь Alias в комментарии довольно убедительно опроверг автора статьи . Приведу его комментарий полностью :

Простите, но мне кажется лучше оставить изначальную формулировку без изменений....
Разных типов, одинаковых типов -- неважно. Документы, созданные в одну секунду, располагаются в произвольном порядке независимо от типа. Другое дело что единожды созданные (расположившись на оси времени) они будут сохранять этот порядок всегда, пока ГУИД останется неизменным.
Получение уникального идентификатора гарантирует только его уникальность, но не возрастание.
В большинстве случаев да, документы будут по порядку. Но это только частный случай! В общем же случае они могут быть и в произвольном порядке.
Согласитесь неприятно будет после нескольких месяцев нормальной работы словить ошибку только потому что вы в своих алгоритмах закладывались на постоянное возрастание момента времени. А это оказалось не так.

В конце концов, проверьте сами -- создайте не 10, а 1.000.000 документов в одну секунду и посмотрите, по порядку они будут идти или нет. Если по порядку -- попробуйте в другой базе, увеличьте число документов, и т.д.

На закуску процитирую слова Бориса Нуралиева:
"Механизм генерации ссылок обеспечивает только их уникальность. Возрастающая последовательность при их генерации не обеспечивается."
Всё сказано вполне чётко, не правда ли?

p.s. Думаю, не стОит напоминать что момент времени -- это время + ссылка, то есть если так будет проще, время + тип документа + уид

2. Второй посткриптум к статье

Чтобы прояснить картину и понять механизм генерации ссылок был проведен эксперимент :
Клиент-серверный вариант 1с82(MSSQL2008),БП2.0.
В трех разных сессиях А,В,С почти одновременно запущены обработки создания и записи 10 000 документов "РеализацияТоваровУслуг" с одинаковой датой-временем. В комментарий каждого документа пишется наименование сессии и порядковый номер создания в сессии.
Например, первый созданный в сессии А документ будет иметь комментарий "А1", а последний "А10 000"

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

С1 ..С32
А1 ..А32
В1 ..В32
А33 ..А224
В33 ..В96
А225..А288
В97 ..В160
...
С33..С96
... и т.д. до С10000,В10000,А10000.

Из полученного порядка расположения документов можно сделать вывод о "захвате" в каждой сессии диапазона ссылок , размер которого кратен числу 32. Подтверждается вывод в постскриптуме 1 о возможности хронологического невозрастания ссылок , если используется несколько сессий. Действительно , эксперимент убеждает в том , что механизм генерации ссылок для одного типа документов обеспечивает лишь уникальность созданных ссылок и ничего более .

С другой стороны, обнаружено , что документы созданные в одной сессии расположены в строго хронологическом порядке их создания, например отфильтрованный список документов для сессии А выглядит следующим образом : А1,А2,А3.....А9 999, А10 000.

На рисунке отображено начало полученного списка документов:

+155 –1

См. также

Файловые потоки в 1С

Механизмы платформы 1С Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

23.06.2024 7521 bayselonarrend 20

154

Сервисы интеграции без Шины и интеграции

Механизмы платформы 1С Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Пример использования «Сервисов интеграции» без подключения к Шине и без обменов.

13.03.2024 5970 dsdred 16

Поинтегрируем: сервисы интеграции – новый стандарт или просто коннектор?

Перенос данных 1C Администрирование СУБД Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)

В платформе 8.3.17 появился замечательный механизм «Сервисы интеграции». Многие считают, что это просто коннектор 1С:Шины. Так ли это?

11.03.2024 14345 dsdred 64

Массивы

Механизмы платформы 1С Программист Стажер Платформа 1С v8.3 Бесплатно (free)

Все мы используем массивы в своем коде. Это один из первых объектов, который дают ученикам при прохождении обучения программированию. Но умеем ли мы ими пользоваться? В этой статье я хочу показать все методы массива, а также некоторые фишки в работе с массивами.

24.01.2024 17824 YA_418728146 26

Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?

Перенос данных 1C Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)

Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?

11.12.2023 11261 dsdred 44

130

1С-ная магия

Механизмы платформы 1С Программист Бесплатно (free)

Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит, быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?».

06.10.2023 23789 SeiOkami 48

135

Начиная с версии платформы 8.3.22 1с снимает стандартные блокировки БД на уровне страниц. Решаем данную проблему скриптом.

Механизмы платформы 1С Системный администратор Платформа 1С v8.3 Бесплатно (free)

Начиная с версии платформы 8.3.22 1С снимает стандартные блокировки БД на уровне страниц. Делаем рабочий скрипт, как раньше.

14.09.2023 18910 human_new 27

Валидация JSON через XDTO (включая массивы)

WEB-интеграция Универсальные функции Механизмы платформы 1С Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

При работе с интеграциями рано или поздно придется столкнуться с получением JSON файлов. И, конечно же, жизнь заставит проверять файлы перед тем, как записывать данные в БД.

28.08.2023 14787 YA_418728146 7

166

Отзывы

16. awa 2610 18.04.11 16:03 Сейчас в теме

Давайте все же попробуем чуть более подробнее разобраться, что же происходит внутри 1С? Как упорядочиваются разные документы внутри одной секунды?
Большинство дальнейших рассуждений не подкреплено никакими пруфлинками, это мой личный опыт копателя внутренностей 1С.

Ссылка на регистратор в регистрах в базе данных хранится в двух полях: _RECORDERTREF и _RECORDERRREF (в зависимости от варианта базы конкретные имена полей могут отличаться, но это не существенно). Первое поле (_RECORDERTREF) это идентификатор типа, второе поле - собственно GUID регистратора.
Упорядочение внутри одной секунды идет сначала по полю _RECORDERTREF, а уже затем по полю _RECORDERRREF. Именно поэтому сначала идут все документы одного типа, и только потом все документы другого типа.
Но что такое этот тип? 1С делает внутреннюю уникальную нумерацию всех хранимых объектов метаданных, табличных частей и реквизитов. Т.е. есть каждый документ, справочник, перечисление, и т.д., а также каждая табличная часть и каждый реквизит имеет свой уникальный номер. Этот номер - просто целое положительное число, порядковый номер. Именно этот номер мы можем видеть, сделав ПолучитьСтруктуруХраненияБазыДанных(), в колонках ИмяТаблицыХранения и ИмяПоляХранения.
Например, имя таблицы хранения документа ПоступлениеДопРасходов - Document252. Значит, внутренний номер типа документа ПоступлениеДопРасходов 252. И именно значение 252 будет храниться в поле _RECORDERTREF регистра.
1С нумерует объекты по порядку. При первичном создании базы из конфигурации объекты получают номера в порядке расположения их в конфигурации. Эти номера не изменяются при дальнейших изменениях базы. Новые объекты получают номера, следующие за максимальным номером в базе. Эта нумерация очень похожа на стандартную нумерацию документов.
Поэтому никакое изменение порядка документов в конфигураторе при уже созданной базе не приведут к изменению внутренних номеров документов, и соответственно не приведут к изменению порядка следования разных типов документов внутри одной секунды. Выход тут один - в конфигураторе выбрать желательный порядок следования типов документов внутри одной секунды путем изменения порядка документов в конфигураторе, а потом из полученной конфигурации надо сделать новую базу. При необходимости, перенести данные с помощью XML, например.
Теперь, что касается поля _RECORDERRREF, т.е. всеми любимого GUID. Много раз встречал утверждение, что 1С не генерит каждый раз новый GUID, а использует один раз сгенеренный в начале сеанса GUID, а потом просто прибавляет каждый раз по единичке, когда нужен новый GUID. Именно поэтому, документы одного типа с временем в пределах одной секунды и созданные в одном сеансе располагаются в порядке их создания. Никаких других гарантий быть не может. Например, если провести эксперимент, что строго по очереди из двух соединений с базой создавать документы одного вида в одной секунде, то фактически, в силу выше описанной особенности создания GUID в 1C, окажется, что сначала идут все документы, созданные в одной сессии, а потом, все документы в другой сессии. (Впрочем, я такого эксперимента не проводил, а просто предсказал результат).
Ну вот, наврено и всё. Всё мною сказанное никак не противоречит со сказанным до меня, а просто, как мне кажется, разъясняет, почему происходит именно так, как говорит фирма 1С.

Ответить

Остальные комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. dvv01 120 18.04.11 09:35 Сейчас в теме

> На мой взгляд, правильно так :
"Но есть особенность - документы разного типа , записанные в одну и ту же секунду, располагаются в произвольном порядке, а не в порядке их физического создания (как было в 7.7). Документы же одного типа располагаются в порядке их физического создания."

У меня получалось так:
Если время создания одинаково и документы разных типов то:
- по временной шкале они сортируются по порядку расположения в деоеве метаданных (если конфа не менялась, то по алфавиту) - обращали внимание при обновлении на настройку режима "порядок объектов". В связи с чем может иметь смысл в конфигурации сдвинуть "Переоценку товаров в рознице" в самое начало до документов перемещения, оприходования, поступления или возврата дабы не нарываться на ошибки "Нет цен АТТ" при перепроведении.

2. Ish_2 1112 18.04.11 09:42 Сейчас в теме

(1) Не знал этого. Явного описания от "1с" этого факта нигде не нашёл.
Нужно пробовать.

3. AnryMc 848 18.04.11 10:35 Сейчас в теме

(0) IMHO - для распределения разных документов на оси времение есть ПОСЛЕДОВАТЕЛЬНОСТЬ

4. Ish_2 1112 18.04.11 10:39 Сейчас в теме

(3) При чем тут "последовательность" ?
"КорректировкаДолга" и "РеализацияТоваровУслуг", приведенные в теме в качестве примера, принадлежат одной последовательности "Взаиморасчеты". И ЧТО ? От чего это спасает ?

59. AlexanderKulikov 21.08.15 07:31 Сейчас в теме

Давайте проведем эксперимент. Создадим простой запрос в 1С с выбором остатков и посмотрим в профайлере на запрос к SQL. Мы увидим там кроме всего прочего такой фильтр (который отсекает движения "не раньше" текущего документа)

...
WHERE (T4._Period > @P3 OR T4._Period = @P4 AND (T4._RecorderTRef > @P5 OR T4._RecorderTRef = @P6 AND T4._RecorderRRef >= @P7)) ....
в качестве P3 и P4 устанавливается время документа (например '4015-08-20 10:42:14')
в качестве P5 и P6 устанавливается тип документа binary(4) ( например 0x0000000C)
в качестве P7 устанавливается ссылка (идентификатор) документа binary(16) ( например 0x83C0AC220BDCDC1D11E52B74AC06CBD9)

Таким образом мы видим что
1. Сравнивается время
2. Если время одинаковое - сравнивается тип
3. Если тип одинаковый - сравнивается ссылка

Естественно, тип и ссылка при изменении документа не меняются. То есть, документ при первоначальной записи в базу данных имеет свое ПРЕДОПРЕДЕЛЕННОЕ место на оси времени внутри секунды.

60. Ish_2 1112 21.08.15 19:16 Сейчас в теме

(59) AlexanderKulikov,
По правде сказать , не очень понял к чему это написано.

Таким образом мы видим что
1. Сравнивается время . ----------Ок
2. Если время одинаковое - сравнивается тип - ОК
3. Если тип одинаковый - сравнивается ссылка ------ОК

Ну, понятно, конечно. И ?
Что нового дало нам Ваше исседование ? Вывод- то какой ?

5. Alias 176 18.04.11 13:40 Сейчас в теме

6. Ish_2 1112 18.04.11 13:53 Сейчас в теме

(5) В таких случаях нужно обязательно указывать ссылку.
Тем не менее звучит убедительно.
Если предположить , что пост (1) верен , то из него вытекает ,
что меняя порядок расположения документа в конфигурации - мы "скачком" меняем "старшие разряды" вновь создаваемых ссылок. И тогда получается , что созданный позднее (после изменения порядка в конфигурации) документ по значению ссылки возможно будет меньше ссылки ранее созданного документа.

7. Alias 176 18.04.11 14:03 Сейчас в теме

(6)
http://partners.v8.1c.ru/forum/thread.jsp?id=279626#279626
имеющие уши, да услышат :) имеющие доступ к партнёрскому форуму -- или знают, или найдут.

По поводу изменения порядка в конфигурации -- не уверен. Мне кажется тип документа (та часть ГУИДа которая определяется типом) определяется в момент добавления объекта в конфигурацию и потом не меняется (при доработках, по крайней мере).

А про тот идентификатор, который 1С примерно называет ГУИДом, можно сказать ещё много чего. Например, та самая "хронологическая последовательность" в пределах одной секунды, о которой говорит автор, легко и непринуждённо может быть сбита, если ГУИД создать программно (УстановитьСсылкуНового()). См. например ветку http://partners.v8.1c.ru/forum/thread.jsp?id=839888#839888, я там тоже писал про это.

P.S. ещё одна цитата от 1С:
"Никакой информации о принадлежности к конкретной ИБ, типу объекта, сессии и др. в GUID нет."
так что не стройте иллюзий. Сто раз получится хронология в секунде, а на сто первый нет. И какой толк тогда будет в том что "а до этого прекрасно работало!"...

8. Ish_2 1112 18.04.11 14:05 Сейчас в теме

(7)В текст темы внесены изменения.

9. Ish_2 1112 18.04.11 14:40 Сейчас в теме

(7) Кстати , а "1с" признает такую неопределенность взаимного расположения документов на оси времени в пределах одной секунды существенным недостатком платформы 8 ?
Действительно , определяя остатки на МоментВремени документа , мы всегда должны учитывать неопределенность : возможно, данные в эту секунду по некоторым документам не попали в запрос, хотя созданы они были "физически" раньше. Мы запросто можем "попасть" на отрицательные остатки !
Ситуация , описанная в теме : "КорректировкаДолга" в последнюю секунду месяца не может учесть долг по документу "РеализацияТоваровУслуг" , записанного в ту же секунду - очень похожа на "косяк".

10. Alias 176 18.04.11 14:54 Сейчас в теме

(9) Существенным недостатком не признают. "Это не является ошибкой, так как именно такое проектное решение было принято" (с)
Ситуация "конца месяца", когда много различных документов вводятся с временем 23:59:59, является особенностью работы системы, которую нужно учитывать.
Рекомендуемым способом "является установка у документов программным способом времени соответствующего желаемому порядку" (с).
Проще говоря, если какой-то документ гарантированно должен стоять раньше другого, единственный способ достичь этого со 100%-ной вероятностью -- установить у него дату с меньшим временем. 23:59:58, например.

11. Ish_2 1112 18.04.11 15:01 Сейчас в теме

(10)
"Это не является ошибкой, так как именно такое проектное решение было принято" (с)
Мммм.. Согласен, это сильно.
Отсюда следует , что поведение документа "КорректировкаДолга" в типовой БП 2.0 как раз не учитывает такой особенности платформы.
Осталось также непонятным , как быть с отрицательными остатками , ведь два расходных документа проведенные в одну секунду непредсказуемо расположены на оси времени относительно друг друга.

12. Alias 176 18.04.11 15:23 Сейчас в теме

(11)
>два расходных документа проведенные в одну секунду непредсказуемо расположены на оси времени относительно друг друга
Будучи единожды созданными, они займут своё положение на оси времени и непредсказуемо относительно друг друга никак скакать уже не будут (ну в смысле в пределах одной секунды). То есть один всегда будет предсказуемо раньше другого, хоть сейчас, хоть через год, хоть после выгрузки-загрузки и т.д.
В случае описанного поведения "Корректировки долга" (впрочем, на его месте мог быть и другой документ) мне кажется это не документ не учитывает поведения платформы, а тот человек, который этот документ создаёт :)

С отрицательными остатками непонятен вопрос. Если абстрагироваться от проблемы одной секунды, появление отрицательных остатков может случиться при любой работе задним числом. Если мы сначала провели один документ в 10:00, а потом другой в 9:00. Граница корректной последовательности в этом случае будет стоять на позиции 9:00. Для восстановления корректной последовательности документ за 10:00 должен быть перепроведен.

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

13. Ish_2 1112 18.04.11 15:46 Сейчас в теме

(12)

В случае описанного поведения "Корректировки долга" (впрочем, на его месте мог быть и другой документ) мне кажется это не документ не учитывает поведения платформы, а тот человек, который этот документ создаёт

Ситуация. Бухгалтеру нужно зачесть авансы в конце текущего месяца. Он начинает делать "КорректировкуДолга" для определенного контрагента. Этот документ должен быть проведен именно в текущем месяце .
И получает примерно следующее сообщение : "Долг по указанному документу не может учтен...". Хм.. обязательно расскажу ей , что она просто не понимает , чего делает в БП2.0.. или что-нибудь про гуид и одну секундычку..

По отрицательным остаткам.
Два оператора в 11:00:00 в пределах одной секунды проводят документы (каждая свой) по расходу товара "ТоварN" (его текущий остаток- 10 шт.). Первый по времени оператор ставит на расход 6 шт. Второй по времени - 5 шт.
Перед проведением документа вторым оператором реально осталось - 4 шт.
Начинается проведение , делается запрос на момент времени второго документа и получаем в результате запроса 10 шт ( второй документ по моменту времени в пределах одной секунды вполне может быть меньше чем первый).
Получили отрицательный остаток. Где здесь "заднее число" ?

17. Alias 176 18.04.11 16:33 Сейчас в теме

(13)
> Где здесь "заднее число"?
Вы же сами себе ответили -- "второй документ по моменту времени в пределах одной секунды вполне может быть меньше чем первый". Меньше -- вот и заднее число. Время то же, но проведение тем не менее задним числом (применительно к единой оси времени).
Когда происходит работа в оперативном режиме, платформа сама контролирует время и создаёт новый документ с приращением +1 секунду, если необходимо.
Если работа неоперативная (то есть оба пользователя установили одно и то же время 11:00, и при проведении оно автоматически не изменилось), сразу появляется вероятность "работы задним числом".

Я же говорю, в этом смысле нет разницы одна там секунда или разные. Это две грани одного и того же явления -- неоперативного проведения документов. Разное время у документов или одинаковое -- может случиться "заднее число". Только если время разное, мы однозначно сразу можем понять будет оно или нет, а в случае одинакового времени -- как повезёт. Может случиться, а может и нет, если документы случайно встанут в правильном порядке.

18. Ish_2 1112 18.04.11 17:03 Сейчас в теме

(17) Ок.

15. Ish_2 1112 18.04.11 15:57 Сейчас в теме

(12) Я извиняюсь. Разумеется,"Оперативное проведение" выключено.

27. Lara.Builova 20.04.11 21:16 Сейчас в теме

(12) >> При первичном создании базы из конфигурации объекты получают номера в порядке расположения их в конфигурации. Эти номера не изменяются при дальнейших изменениях базы.
>> в конфигураторе выбрать желательный порядок следования типов документов внутри одной секунды путем изменения порядка документов в конфигураторе, а потом из полученной конфигурации надо сделать новую базу

Возможно ли объяснить потерю данных в случае обновления базы с помощью метода "загрузить конфигурацию из файла", когда сфшник подготовлен в другой базе и там в конфигураторе изменен порядок следования объектов в дереве (добавили новый и для удобства выстроили по алфавиту)?

31. awa 2610 21.04.11 12:24 Сейчас в теме

(27) Не совсем понял вопрос. Но попытаюсь еще немного рассказать про внутреннее устройство 1С. Может быть это поможет Вам самой ответить на свои вопросы.

Внутри конфигурации все объекты конфигурации, все табличные части, реквизиты, а также разные типы имеют свои GUID. Большинство из этих GUID стандартными средствами узнать невозможно. Когда из конфигурации создается база данных, как я уже говорил ранее, хранимые объекты метаданных, табличные части и реквизиты получают свой порядковый номер. Соответствие внутренних GUIDов порядковым номерам базы хранится в записи DBNames таблички PARAMS. Вот, для примера, кусочек DBNames:

{2fa7fd11-0137-4a42-bf70-986b5d658d65,"Reference",12045},
{a129de8f-cdab-46f0-8a34-044183a85196,"Fld",12046},
{2a8e1b68-4237-4763-9830-84f8d4263f5b,"Fld",12047},
{259bed08-4ffb-4724-91e6-fa015561fed6,"Fld",12048},
{703d21d1-2377-4740-87c3-b092e257b741,"Fld",12049},
{33e695c2-6d2c-472d-8984-7303b217ee21,"VT",12050},
{33e695c2-6d2c-472d-8984-7303b217ee21,"LineNo",12051},
{653dbcae-2fca-4d7d-ac56-a43a14257078,"Fld",12052},
{bd2d6f08-d402-4433-bffc-f3dc24537fb5,"Fld",12053},
{7886e478-a88a-46d0-a375-4ee567ac643d,"Fld",12054},
{89afe865-ab1d-4b65-b094-afbd3752fc93,"Fld",12055},
{f7ac11fb-7efe-493d-a90a-088a212f5497,"VT",12056},
{f7ac11fb-7efe-493d-a90a-088a212f5497,"LineNo",12057},
{9e9d4780-d640-41db-adeb-33adf5462152,"Fld",12058},

Показать

Кроме GUID и порядкового номера, как можно видеть, здесь еще есть тип объекта (в данном примере Справочник, Реквизит, Табличная часть, Номер строки) и некоторым GUIDам может соответствовать несколько номеров разных типов (для табличной части, напрмер, есть номер таблицы и есть номер поля Номер строки).

Давайте, теперь посмотрим, что происходит при редактировании конфигурации. При добавлении новых объектов, ТЧ и реквизитов для них генерятся новые GUID, естественно. Но, если мы например, просто изменили имя существующего реквизита или, например, документа, то внутренний GUID объекта при этом не изменится. А вот если мы удалим реквизит и тут же его добавим снова с тем же именем, типом и т.д. то внешне ничего не изменится, но внутренний GUID будет другим! Я думаю, тут все логично и понятно.

Осталось рассмотреть, что происходит при обновлении конфигурации.
Если мы обновляем конфигурацию в режиме "сравнить и объединить", то 1С сначала сопоставляет объекты из старой и новой конфигурации по внутреннему GUID, таким образом, например, 1С сможет определить, что мы изменили имя реквизита или документа. Для тех объектов, что по внутреннему GIUD не сопоставились, производится попытка сделать сопоставление по имени. На этом этапе 1С сможет сопоставить старый и новый реквизит, даже если мы, как в примере выше, удалили реквизит и снова его создали. Все сопоставленные объекты сохранят свои порядковые номера в базе данных, а значит информация при обновлении не потеряется.
Но в случае загрузки конфигурации из файла сопоставление идет только по внутренним GUID, так как нет промежуточного сравнения со старой конфигурацией, а сопоставление, по сути, идет только в момент обновления базы данных между GUID новой конфигурации и GUID в записи DBNames. Те объекты из загруженной конфигурации, GUID которых сопоставился со строчкой в DBNames, сохранят порядковый номер, и соответственно, сохранят данные. Т.е. в случае измененного имени реквизита или документа из примера выше данные сохранятся. Но для случая удаленного реквизита и добавленного снова, так как GUID этого реквизита теперь другой, 1С выделит для него новый порядковый номер XXX, соответственно, в нужной табличке создаст поле FldXXX, а поле FldYYY, где YYY - старый порядковый номер рекизита, удалит. Т.е. в этом варианте произойдет потеря данных.

Сорри за, по сути, оффтоп.

Возвращаясь к вопросу в (27), из всего вышесказанного следует, что простое изменение порядка объектов в конфигурации не приведет к потере данных. К потере приводит удаление и создание заново объектов. Например, решили обновить документ путем копирования из другой конфигурации, удалили существующий документ и через буфер обмена вставили документ из другой конфигурации (при копировании GUID не сохраняются!).

Ответить

32. cool.vlad4 2 21.04.11 12:36 Сейчас в теме

(31) :D побольше бы таких оффтопов

33. Ish_2 1112 21.04.11 15:44 Сейчас в теме

(31) Прочитал , почесал в затылке.
Признайся , Валера, такая аналитика не может быть профессией.
А может быть только - хобби.

35. awa 2610 21.04.11 17:16 Сейчас в теме

(33) Да, Игорь, это не профессия, мне за это не платят ))
(34) Все-таки я думаю, что причина в

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

как я говорил выше, при такой вставке мы получаем внутренние GUID объектов, не совпадающие с конфигурацией поставщика. И в дальнейшем избавиться от этих неправильных GUIDов практически невозможно - при обновлении путем "сравнить и объединить" даже с конфигурацией поставщика остаются неправильные GUID. Способ заменить эти GUID на правильные: 1) загрузить конфигурацию без сравнения. Данные будут потеряны; 2) Создать новую базу из конфигурации поставщика, и данные туда перенести из старой базы.
А вообще, 1С не предоставляет нормальных средств для отслеживания таких ситуаций, на партнерском форуме вроде даже ветка была, где просили сделать возможность при сравнении/объединении выбрать вариант "для объектов, сопоставленных по имени взять GUID из новой базы". Однако ж, воз и ныне... ))

36. Lara.Builova 21.04.11 18:52 Сейчас в теме

(35) Спасибо за ответы.

37. Ish_2 1112 23.04.11 13:02 Сейчас в теме

(35) Ну , раз хобби - давай "хоббировать". И проверим предположение в (16):

Проведем простейшее исследование для клиент-серверного варианта 8.2(MSSQL).
Создадим в хронологическом порядке 3 сессии : Сессия А,Сессия В, Сессия С.
В каждой из сессий будем записывать документы с одинаковым временем 30.04.2011 23:59:59 и префиксами соответсвующими названию сессии (префиксы СессияА,СессияВ,СессияС).

Экперимент № 1.
В каждой из сессий запишем документы в следующем хронологическом порядке :
СессияА1,СессияС1,СессияВ1. В журнале они будут располагаться в следующем порядке :

СессияА1,
СессияС1,
СессияВ1.

Другими словами , "как ввели - так и получили".
Хотя сессия С была создана позже Сессии В - тем не менее мы получили , что ссылка в сессии С меньше ссылки в сессии В. Отсюда следует , что фраза в (16) о "сгенеренном в начале сеанса GUID" - неверна.
Думаю предпочтительнее полагать , что начальный GUID для текущей сессии генерируется не в момент запуска сессии , а в момент первого обращения для создания ссылки.

Эксперимент № 2.
Все последующие записанные документы (каждый в своей сессии) располагались каждый в своём диапазоне в строго хронологическом порядке (по возрастанию ссылок), что в целом подтверждает предположение (16). См . рисунок.
Думаю также , что предложение в (5) создавать множество документов в одном сеансе для того , чтобы "сбить" последовательность возрастания ссылок смотрится малоперспективным. Действительно, хронологическое невозрастание ссылок документов легко достигается при использовании нескольких сеансов.

Прикрепленные файлы:

38. awa 2610 23.04.11 14:53 Сейчас в теме

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

СессияА1,
СессияС1,
СессияВ1.

, совпадающий с хронологией создания документов.
Но, если сессии открывать на разных компьютерах, или на одном компьютере, но через большие промежутки времени, вполне вероятно, что и эта зависимость пропадет. Да и в рамках одной сессии, где гарантия, что, в 1С нет какого-нибудь счетчика, и что, например, после 1000 раз прибавления к GUID по единичке, 1С не возьмет, и не сгенерит совсем новый GUID? Это знают только разработчики 1С.
Так что, имхо, с уверенностью можно предсказать только порядок следования разных типов документов в рамках одной секунды в каждой конкретной базе, но не порядок документов одного типа.

39. Ish_2 1112 23.04.11 15:26 Сейчас в теме

(38) Конечно, все три сессии были созданы на одном компьютере с интервалом 20-30 сек.
Проведем более содержательный тест : в каждой сессии А и С одновременно запускаются процедуры записи 100 000 документов с одной датой-временем. Узнаем возможны ли разрывы в расположении документов в журнале или документы из каждой сессии будут располагаться строго в "своем" диапазоне(диапазоне своей сессии).

40. Ish_2 1112 23.04.11 16:48 Сейчас в теме

(38) Экперимент был следующий : даны три сессии А,В,С (запущены в каком-то произвольном порядке).
В каждой сессии с интервалом в 4-5 сек. запускается процедура создания и записи 10 000 документов "реализацияТоваровУслуг" с соответсвующим букве сессии комментарием (например, первый созданный в сессии А документ имеет комментарий А1 и т.д.)

Результат выполнения трех процедур в разных сессиях наблюдаем в списке документов "РеализацияТоваровУслуг".
Получили документы в следующем порядке :
С1 ..С32
А1 ..А32
В1 ..В32
А33 ..А224
В33 ..В96
А225..А228
В97 ..В160
...
С33..С96
... и т.д. до С10000,В10000,А10000.

О закономерности тут судить трудно. Но.
На данный момент имеем , что предположение в (16) неверно.
Созданные ссылки в разных сессиях лежат не каждая в своем "назначенном" диапазоне , а вперемешку причем по непонятной закономерности.
Желательно , конечно, чтобы кто-то еще повторил этот эксперимент.
На рисунке начало списка документов , созданных одновременно в 3 разных сессиях :

Прикрепленные файлы:

41. awa 2610 23.04.11 17:51 Сейчас в теме

(40) Очень похоже, что счетчик, про который я говорил в (38), равен 32. Т.е. 1С генерит уникальный GUID, скорее всего с помощью вызова WinAPI-функции UuidCreate, и затем использует данный GUID для получения 32 последовательных значений, прибавляя каждый раз по единичке. Потом снова генерит новый GUID, и получает новый блок из 32 последовательных GUID, и т.д.
Проверить это можно посмотрев сами GUID в базе. Если база файловая, то проще это сделать с помощью Tool_1CD, только надо отключить опцию "Отображать Binary(16) как GUID".
Правда, блок А225..А228 выбивается из предположения про счетчик на 32.

42. Ish_2 1112 23.04.11 18:05 Сейчас в теме

(41)А225..А228. Конечно, это опечатка.
Правильно А225...А288 (64 документа) .

43. Ish_2 1112 23.04.11 18:28 Сейчас в теме

(41) И вот ещё что. Как и ожидалось , в каждой сессии обеспечивается возрастание ссылок.
Другими словами , если сделать отбор в списке документов по комментарию начинающемуся с "А",
то все документы в списке расположены в строгом порядке их создания :
А1,А2,А3,.....А9999, А10000.
Аналогично для "В" и "С".

Контроль осуществлялся с помощью простейшей процедуры :

Выборка = Документы.РеализацияТоваровУслуг.Выбрать(НачалоДня(Дата(2011,8,31)),КонецДня(Дата(2011,8,31)));
Пред = 0;
Пока Выборка.Следующий() Цикл
	Если Найти(Выборка.Комментарий,"С")=0 Тогда
		 Продолжить;
	КонецЕсли;
	Строка =  СтрЗаменить(Сред(Выборка.Комментарий,2),Символы.НПП ,"");
	Число = Число(Строка);
	Если Число > Пред Тогда
		 Пред = Число;
	Иначе
	        Сообщить("***********"+ Выборка.Комментарий);
	КонецЕсли;
КонецЦикла;

Показать

34. Lara.Builova 21.04.11 15:45 Сейчас в теме

(31) Я ломаю голову над одной проблемой, когда у меня пропали не только данные, но и реквизиты в конфигураторе.
База была в таком состоянии, что работать у клиентов на их медленных машинах было невозможно.
Частично снята с поддержки, обновления делались путем кусочного вставления того, что прог считал необходимым из разных релизов. Основная конфигурация состояла из такой вот мозаики. Конфигурация поставщика тоже не соответствовала номеру релиза, ~~вытащенного~~ определенного Вашей програмкой Tool_1CD, то есть тоже умудрились ее покромсать. Задача была поднять последовательно все релизы (примерно 10), убрать все хвосты, обычно удаляемые сфу-шником, ненужные с определенного релиза реквизиты (типа удалитьПодразделение). Делалось это на копии базы дома, проверены были все добавленные предыдущими прогами объекты - все на месте, данные на месте. При замене конфигурации у клиентов некоторые реквизиты улетели, причем те, что были воткнуты и в конфу поставщика.
Новая конфигурация поставщика, вычищенная от добавлений, замела те же реквизиты и в основной - вот тут я как то не поняла почему.

14. cool.vlad4 2 18.04.11 15:48 Сейчас в теме

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

16. awa 2610 18.04.11 16:03 Сейчас в теме

Ответить

19. Ish_2 1112 18.04.11 17:25 Сейчас в теме

(16) Прочитал мельком.
Интересно. Вполне стоит оформить отдельной статьёй.

20. Ish_2 1112 18.04.11 17:58 Сейчас в теме

(16)

Много раз встречал утверждение, что 1С не генерит каждый раз новый GUID, а использует один раз сгенеренный в начале сеанса GUID, а потом просто прибавляет каждый раз по единичке, когда нужен новый GUID. Именно поэтому, документы одного типа с временем в пределах одной секунды и созданные в одном сеансе располагаются в порядке их создания. Никаких других гарантий быть не может. Например, если провести эксперимент, что строго по очереди из двух соединений с базой создавать документы одного вида в одной секунде, то фактически, в силу выше описанной особенности создания GUID в 1C, окажется, что сначала идут все документы, созданные в одной сессии, а потом, все документы в другой сессии.

Отсюда вытекает , что если в первой сессии ссылки для документа начинаются с N , то во второй сессии
ссылки должны начинаться с N+M.
Вопрос : если количество созданных документов в первой сессии очень велико , то тогда в первой сессии мы можем достигнуть значения N+M , т.е. получаем дублирование ссылок в первой и второй сессии.
Я правильно всё понял ?

21. awa 2610 18.04.11 18:33 Сейчас в теме

(20) Теоретически да. Но GUID - это 128-битное число, и, как я понимаю, механизм генерации GUID сделан так, чтобы M было очень большим. Таким большим, что столько документов в базе просто не бывает. Но на самом деле, реальных познаний в алгоритме генерации GUID у меня нет. Остается только надеяться, что 1С это учла и проверила.

22. Ish_2 1112 18.04.11 18:46 Сейчас в теме

(21) Понимаю , что это всего лишь предположения. Тем не менее.
Ежедневное количество К открываемых сессий может быть большим. Для каждой сессии мы с большим запасом должны определить некоторое M. И тогда для последней сессии получим начальное значение счетчика К*М .
Отсюда и сомнение : Не исчерпаем ли мы достаточно быстро всю "емкость" ссылок ?
Вероятно , нам неизвестен какой-то нюанс в назначении ссылок.

23. awa 2610 18.04.11 19:42 Сейчас в теме

(22) 128-битное число - это ОЧЕНЬ большое число!
Википедия про UUID

Общее количество уникальных ключей UUID составляет 2^128 = 256^16 или около 3.4 × 10^38. Это означает, что генерируя 1 триллион ключей каждую наносекунду, перебрать все возможные значения удастся лишь за 10 миллиардов лет.

Но, если мы все же внезапно сгенерируем существующий GUID, то мы просто получим ошибку при записи в базу данных из-за неуникальности индекса. Эту ситуацию можно искусственно воспроизвести с помощью УстановитьСсылкуНового().

24. DoctorRoza 19.04.11 22:25 Сейчас в теме

23ч.59м.59с. .. спать нужно, а не документы проводить .. :D

25. Ilyabaykov 121 20.04.11 16:27 Сейчас в теме

Не забываем про журналы, если режим времени текущее или последним, то документ гарантированно встанет за последним документом, принадлежащим данному журналу, даже если они разных типов. Однако так-же не забываем, что много документов на 23:59:59 это потенциальный источник ошибок.

26. Ish_2 1112 20.04.11 19:45 Сейчас в теме

(25)
Правильно ли я понял , что все пред. утверждения к Журналам и СпискамДокументов не относятся.
Другими словами, при неоперативном проведении, в журнале или в форме списка документов - записанные в одну секунду документы будут располагаться в сверхточно - хронологическом порядке их создания ? Так ?

28. Ilyabaykov 121 20.04.11 22:06 Сейчас в теме

(26) Документы будут располагаться так, как вы их расположите :) Если нам надо, что-бы документ располагался в конце дня, или начале дня, в рамках журналов, которым он принадлежит, то сделать это мы можем, но не установкой времени при помощи Дата = '20110131235959' а используя метод "УстановитьВремя". Работает естественно только в рамках журнала, которому принадлежит документ.
Для документов, никак не связанных (последовательностями или журналами) расположить в "правильной" для нас последовательности довольно сложно, но здесь нас выручает блокировка данных! да, не смейтесь, если-бы первый оператор из примера в (13) заблокировал "свои" остатки, то второй оператор ждал-бы завершения проведения его документа и увидел-бы уже правильные остатки.
Вообще странная дискуссия - какой документ раньше, тот, который на 23:59:59 или тот, который на 23:59:59 :)
Если такие проблемы возникают это должно решаться четким пониманием какой документ должен быть на каким и соответственно распределять их по шкале времени, но не в пределах одной несчастной 23:59:59 а например 23:59:57 и 23:59:58.

29. Ish_2 1112 20.04.11 23:12 Сейчас в теме

(28) Нет слов.

30. Ilyabaykov 121 21.04.11 00:34 Сейчас в теме

(29) Что именно вызвало у Вас немоту? на самом деле по поводу размещения документов в пределах одной секунды совершенно прав awa в (16) и с этим ничего не поделаешь, так реализовано в платформе. А я лишь хотел сказать, что если последовательность документов сильно критична для системы, система-же и должна контролировать правильность ввода. Например закрытие месяца - только на 23:59:59 и только его. а переоценку товаров - только в начало дня.
Касательно непредсказуемости распределения документов в пределах одной секунды - документы, заняв позицию на временной оси один раз, со своего места уже не уйдут, разве что у ранее созданного документа не поменяют время и он вклинится перед "нашим" документом (GUID меньше).
А то, что остатки на конец дня, могут не совпадать с входящими на следующий день - это надо иметь в виду, и пользователям об этом тоже можно говорить, дабы повнимательнее были со временем документа.

44. Ish_2 1112 23.04.11 18:49 Сейчас в теме

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

	НачатьТранзакцию();
	Для н=1 по 10000 Цикл
		Объект = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
		Объект.Дата = Дата(2011,8,31,23,59,59);
		Объект.Комментарий = "А"+н; // В обработке для второй сессии использовалось "В",
                                            //Для третьей сессии "С".
		Объект.Записать(РежимЗаписиДокумента.Запись);
		Если н%1000=0 Тогда
			 ЗафиксироватьТранзакцию();
			 Сообщить(" "+н);
			 НачатьТранзакцию();
		КонецЕсли;	 
	КонецЦикла;	
	ЗафиксироватьТранзакцию();

Показать

45. maxx 996 24.04.11 21:53 Сейчас в теме

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

46. Ish_2 1112 24.04.11 22:05 Сейчас в теме

(45) Вообщем-то , конечно, подробно копать в механизме генерации ссылок смысла мало. Но ведь хобби..
Да и началось всё с простого практического вопроса : почему в типовой БП20 документ "КорректировкаДолга" не закрывает авансы по другому документу.

47. puzano-v 147 27.05.11 20:40 Сейчас в теме

Отличие 1с8 от 1с7 в том, что доступ к документам в 1с7 ведется через общий журнал, который отсутствует в 1с8.
поэтому документы на последней секунде располагаются в любом порядке (очивидно).
Для убедительности зайдите на сервер и посмотрите текст запроса 1с по отбору документов для 1с7 и 1с8.
( сложных запросов писать не надо ).

48. Ish_2 1112 31.05.11 09:59 Сейчас в теме

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

49. AlexO 135 27.12.11 01:28 Сейчас в теме

Так и что решили?
1С умыла руки - "мы так решили, и следите за своими остатками сами", тут еще про свободу какую-то в 1с говорили.. это совсем смешно: "свобода в 1с!".
Одни рамки и ограничения. А также узость мышления создателей платформы и их методологов.
Таким образом - проблема разновидных доков в одной секунде нерешаема? и создаются они случайным образом?
"Мы решили, что будет хаос - разгребайте сами"?

50. Ish_2 1112 27.12.11 16:01 Сейчас в теме

(49)

Одни рамки и ограничения. А также узость мышления создателей платформы и их методологов.

Полегче на поворотах.
Чтобы так утверждать, нужно как минимум предложить свой безупречный механизм упорядочивания документов на временной оси.
У Вас он есть ? Давайте обсудим.
Мой же взгляд , на эту проблему менялся от "очевидного косяка платформы" до "неприятного следствия вполне осознанного решения разработчиков платформы". Дело в том, что любой механизм упорядочивания документов на временной оси не будет лишен недостатков. Судя по всему, существующий вариант механизма разработчики сочли наименьшим злом. Грубо говоря , предлагается убойный по простоте подход :
" не создавай кучу документов в одну секунду !"

51. AlexO 135 07.01.12 02:42 Сейчас в теме

(50) >> Полегче на поворотах.
это бы 1с-у скажите ))
а то учет учетом, но такие перлы вылазят постоянно...
>> нужно как минимум предложить свой безупречный механизм упорядочивания документов на временной оси
а его и не нужно предлагать - все уже изобретено: все ОС позволяют получить и учесть доли секунды, так почему 1С привязалась к секунде? И это не "подход : " не создавай кучу документов в одну секунду !", а ограничение платформы, т.к. создать "кучу документов в одну секунду" норовит сама платформа, а не оператор.
Кто создает в 1 сек несколько документов - платформа или умысел?
Да и тут все можно было разрулить учетом сотых долей секунды. Влегкую.
Или можно было признак дополнительный ввести - навроде "нумерации в пределах неделимого момента времени", и отталкиваться от него, а за основу брать порядок физического расположения записей в базе.
Да много чего можно было сделать.
А главное - можно было в принципе не допускать такого события.
Но обработка и отслеживание ошибок - далеко не самая сильная сторона 1С.

52. jobkostya1c_ERP 100 26.03.12 10:30 Сейчас в теме

Очень полезная статья. Изучая суть момента времени Попутно возникает следующий вопрос: если введены несколько документов одного типа в одну и туже секунду как программно изменить их место расположение, т.е. поменять момент времени. Задача в частности сводится к тому, чтоб программно записать новый документ ОперацияБух позади регламентной операции без ее перепроведения, время которой как раз составляет последнюю секунду месяца.

53. AlexO 135 26.03.12 10:49 Сейчас в теме

(52) kostyaomsk,
никак.
Никакого механизма отслеживания и распределения в определенном порядке в базе в 1с нет.
Вы можете поменять в МоментеВремени объекта только время. Вот этим и рулите.
Да. еще можете извернуться и УИД поменять. Но оно вам вам нужно?

58. jobkostya1c_ERP 100 28.06.14 21:03 Сейчас в теме

(53) AlexO, в итоге учитывая весь опыт в общем "не надо так внедрять". Только два выхода:
1. Оставлять интервал между документами (10 секунд) и в конце тоже 10 секунд "на крайний случай". На это был целый лист служебной записки. Так сказать внутренние стандарты фирмы для разработки
2. Можно создать в конфигурации новый документ только для подобных случаев чтоб он точно записывался последним. Для этого необходимо лезть в механизмы хранения файлов чтоб понять как сортируются ссылки (например понять что сравнивает встроенная функция "МоментВремени().Сравнить(<ДокСсылка>)". Ну это уже если совсем крайний случай.

54. Ish_2 1112 26.03.12 12:04 Сейчас в теме

(52) Сам я не знаю , как это корректно и легально сделать.
А Вы попробуйте !
И потом напишите как заменили ссылки и что получилось.
Я почитаю с удовольствием.

55. red80 20.04.12 14:57 Сейчас в теме

>> Но есть особенность - документы разного типа , записанные в одну и ту же секунду, располагаются в произвольном порядке, а не в порядке их физического создания (как было в 7.7). Документы же одного типа располагаются в порядке их физического создания.

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

56. red80 20.04.12 15:02 Сейчас в теме

Еще:

В запросе можно сравнивать .МоментВремени (!), но в агрегатных функциях использовать нельзя.

57. BraunAlex 136 26.06.14 22:15 Сейчас в теме

Из справки 1С
"Последовательности
Последовательности предназначены обеспечения проведения документов в непрерывной хронологической последовательности. Последовательность может иметь измерения, в разрезе которых можно контролировать и поддерживать последовательность проведения документов. Существует также доступ к записям регистрации отдельных документов в последовательности." ©

61. AlexanderKulikov 07.09.15 11:11 Сейчас в теме

Да, собственно, одной строкой кода показал как это происходит в запросе. Лично мне - так проще.

62. SoDm 8 24.12.15 07:26 Сейчас в теме

На закуску процитирую слова Бориса Нуралиева:
"Механизм генерации ссылок обеспечивает только их уникальность. Возрастающая последовательность при их генерации не обеспечивается."

Вы уверены, что это слова Бориса Нуралиева, а не Сергея Нуралиева?

63. timeforlive 16 13.12.19 03:00 Сейчас в теме

Первый посткриптум к статье.
Опечатка:
Постскриптум

64. Ish_2 1112 16.12.19 16:09 Сейчас в теме

(63) Да, ошибка. Спасибо.
Пусть останется как есть.

Оставьте свое сообщение

E-mail:

Автор:

Игорь Исхаков (Ish_2)

Рейтинг: 1112

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 84177

Создание 18.04.11 08:10

Обновление 27.04.11 12:59

Статистика:

Просмотры 63686

Загрузки 123

Рейтинг 154

Комментарии 64

Характеристики:

Код открыт Не указано

Рубрики Механизмы платформы 1С

Кому Программист

Тип файла Внешняя обработка (ert,epf)

Платформа Платформа 1С v8.3

Конфигурация Конфигурации 1cv8

Операционная система Не имеет значения

Страна Россия

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)