Что-то никак не пойму.

В свойствах строки ТЧ только НомерСтроки и реквизиты

Нет

А как тогда сама платформа идентифицирует строки, очень интересно??

(3) например для чего ей индентифицировать строки?

с какой целью интересуешься? Открой для себя книгу "Профессиональная разработка..."

а номер строки чем не нравиться ?

(4),(6)
Исходя из ваших постов, я понимаю, что при каждой записи документа платформа просто перезаписывает... Табличную часть документа?

(6) видимо тем, что сортировку\перемещение строк никто не отменял.

(5)
Мне рано еще читать книги для взрослых.

(9) так может и 1С не твое еще, рано

(10)
Может быть. Но вопрос задан. Есть соображения - отвечай.

(11) так ответили уже нет идентификаторов для строк и нафиг платформе не нужны

+(12) но если с какой-то умной целью нужны, то можно организовать самому

(12)
Ага. С одной стороны, строка - полноценный объект и самостоятельная сущность. Причем, чуть ли не из самого сердца БД.

С другой стороны, по мнению drShad - "нафиг платформе не нужны".

Тогда как можно предположить, даже не залезая в саму БД - что GUID-ы строк там есть, просто платформа не даёт к ним доступ.

Что очень жаль.

(14)[строка - полноценный объект и самостоятельная сущность.]
не верю

(14) да нет там никаких GUIDов

(12) платформе вообще никакие объекты не нужны - они нужны разработчику.

(15)
Твое дело. Нормальный ORM тебе модель не построит без primary key в  таблице. Если только read only.

(18) ты можешь сказать нафига они тебе впились?

(18) Да ну

(18) бла бла бла
первичный ключ у документа

(19)
Делаю синхронизацию с внешней системой.

Да ладно, парни, я всё понял.

(21)
Что это было?
Мастер-класс от shuhard-а?

(23) ага, многтим помогает :)

(24) но не всем

При записи объекта:
1) 1С не переписывает ТЧ, если ТЧ не менялась
2) 1С переписывает те строки ТЧ, которые менялись
3) 1С переписывает все строки ТЧ, если изменился порядок строк.

У строки нет идентификатора (и нафиг не нужен)

(26)
"2) 1С переписывает те строки ТЧ, которые менялись
3) 1С переписывает все строки ТЧ, если изменился порядок строк."

Теперь понятно.

Если удаляем одну строку из 500-ста, значит - изменился порядок строк, значит перезаписываем всю ТЧ.

И конечно же из этого следует, что UID строке не нужен.

Совсем 1С мозги проела?

(28) а разве когда-то у 1С было по-другому?

(28) Че ты там список захотел штоли? Это еще +32 байта на строку.

Если односвязный список.

(29)
Да меня как бы не совсем взолновывает, как это было у 1С.
И внешний UID завести совсем не проблема.

Меня удивляют, высказывания "некоторых", которые считают, что UID строке - нафиг не нужен.

Полторы тыщи строк на вашем любимом тонком клиенте - строку удаляем - и понеслась ненужная перезапись всего объема? В ином случае - достаточно было бы одной строчки.

Так системы не проектируют, как бы...

(15)
Ты, красава, код посмотри, как сторки добавляются. Потом взгляни на структуру таблиц БД. Ну а потом книжку какую-нибудь умную почитай, причем, избегай желтых цветов. Глядишь - и поймешь.

<< В ином случае - достаточно было бы одной строчки.>>
2-х, или даже 3-х (но необязательно).

(28),(32) Пожалуйся разработчикам...По теме ответили. А если тебя не устраивает, то твоя проблема.

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

Записать в базу полторы тыщи строк - это пустяк.

(36)
Э-э-э-э...
Ну как бы, если речь идет о работе в локалке - тогда да.

А вот если гонять 1500 тыщи строк между сервером и каким-нибудь мобильным терминалом, да еще и в XML - то поневоле захочется "добавить 32-байта".

Че там?
1) Ввел документ - и лежит он себе, ну поменял пару раз строки, подождал.
Лежит дальше.
2) Ввел документ - и лежит он себе с лишними 32 байтами на строку, и не факт, что порядок строк когда изменится.

Идентификатор документа + табличная часть + номер строки не пробовал использовать?

(37) "Хочется" и "нужно" - разные вещи.

(40)
Как будет угодно.

для SQL у строки ДОЛЖЕН быть идентификатор, только не в виде гуида а в виде индекса строки в таблице (не путать с номером в табличной части), без этого кластеризованый индекс не построить...

только этот идентификатор в 1с недоступен :) это уровень базы данных

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

По этому не нужно связывать 1с и SQL это "красный" и "теплый"

(42)
Ну, тутошнему люду UID у строки "и нафиг не нужен".
Звучит весомо.

А как насчет редактирования одного документа несколькими людьми?

А разрешение коллизий в разных узлах ИБ на уровне строк?

Один оператор в одном городе меняет одну строку, другой оператор - другую.

Все изменения будут приняты?

(43) вполне нормальным будет решение документ+РегистрСведений, при этом ты все свои вопросы решаешь, да и устроки РС есть идентификатор доступный внутри 1с.

просто идеология 1с - "объект не делим" это относится к документу в целом, если тебя это не устраивает - вместо ТЧ используй РС.

зы
только зачем изобретать велосипед? и наступать на грабли? уверяю что если у тебя возникают траблы типа (43) - значит ты не правильно спроектировал документы (сделал вместо 10 документОв один мега докУмент)

Приоритет у центральной базе, если не оговорено (настроено) особо. Работа с SQL базой от 1С напрямую не предусмотрено (не приветствуется)

(44)
" значит ты не правильно спроектировал документы "

Увы, есть варианты, когда бизнес-процессы утверждаются сверху.

Могу привести примеры.

(46)Давай

(46) бизнес может утверждать только видимою часть (формы), но как ты это реализовал - бизнес даже знать не должен

(48)
Бизнес-процесс может выкидывать какие угодно фортеля и из-за каждого чиха перекраивать значительную часть системы?

Торговые представители работают с контрагентами. С одним контрагентом могут работать неограниченное количество торговых.

У каждого свой тип товара, каждый работает только в своей зоне.

Все это решалось договорами и различными привязками к этим договорам.

Но иной клиент хочет всё в ОДНОЙ накладной + вести взаиморасчеты по этой накладной.

То есть - все типы товара физически находятся в одном документе.

Но торговый всё также должен иметь/влиять только на свою зону отвественности.

Ну вот и всё. Документ по сути могут реадктировать несколько людей, причем значительно разнесенных в пространстве.

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

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

(48) +100500

Сводные документы совсем не так делаются

UID строке не нужен (С)
Просто отметился

отлично. Давайте теперь каждый обновляльщик типовых выдумает "похожую" задачу и что-нибудь здесь пропищит. Сводные документы уже вход пошли.

В каждой нормальной системе у сущности есть PK. не нужен он только 1С-никам и уппыристам, у них и без того забот полон рот.

(56) пойми, что в 1с документ это и есть неделимая сущность! и у документа есть свой UID.

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

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

Да все я понимаю. Не понимает только торговый, который добавляет на своем терминале +50 строк, а оператор в офисе - удаляет одну; и все +50 строк улетают в бездну, так сервер видите ли WINS.

разумеется, будет в итоге синхронизация на уровне строк.

Меня упертость отдельных лиц восхищает, которые согласны на сервер посылать ВСЕ строки в принципе, ради одной удаленной или добавленной.

(50) а что мешает делать одну реализацию по нескольким заказам контрагента ?

UID строке не нужен (с) не мое, но это правда :)

а в дереве значений есть

(58) ну, эта ситуация встречается в одном случае из 50 миллионов. Нафига 1С- отдельно обрабатывать такую странную ситуацию, если в 99,9% случаев никто никаких строчек не удаляет и порядок строк не меняет? Да еще и офигенные идентификаторы строк, которые в несколько раз затормозят систему? Ты думаешь на самом деле в 1С полные придурки сидят, чтобы такую фигню делать?

(0) Если говорить про форму 8.2 то ответ - есть , иначе нет .

(62)
"ну, эта ситуация встречается в одном случае из 50 миллионов"

Дедушка, какая ситуация? Ты уверен, что правильно буквы понял?

"если в 99,9% случаев никто никаких строчек не удаляет и порядок строк не меняет?"

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

Подумать только, редактирование документа - странная ситуация.

"Ты думаешь на самом деле в 1С полные придурки сидят"
На заданный вопрос отвечаю - думаю, что придурки сидят в другом месте.

Говорят "нет". получил ответ?

(64) Стена, ядъ.

(64)
<<Дедушка>> hhhh все правильно написал. Очень редко возникает ситуация, когда юзеры меняют состав строк в ТЧ. Поэтому заводить под ТЧ односвязный список (простейшая структура) - неоптимально.

(67)
Удаление строки - это смена состава строк?

(68) Да.

(68) Рекомендую тебе как - нибудь побывать на большом оптовом складе, где торгуют ну хоть бы водкой и посмотреть процесс выписки документов :-)

Очень редко возникает ситуация, когда юзеры меняют состав строк в ТЧ.

Удаление строки - это смена состава строк?

Да.

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

Мда... Чоткие у вас юзеры, чо.

(71)Что ты хотел доказать \ показать \ узнать своей веткой?

(71) Решение задачи в лоб. Не лучшее в данном случае решение...
А если так:
1. Торговые представители оформляют заявки от покупателя.
2. На складе, в логистике, выписавают на основаниии заявок один документ отгрузки. который отправляетс заказчику.

Это типовой метод, как ни странно.

вообще самое логичное решение конкретной задачи:

1. менеджеры создают N предворителельных документов
2. ответсвенный за выдачу генерит на основании одну накладную
3. при необходимости изменения данных менеджерами они создают сторнирующие документы

при таком подходе и накладная будет одна и данные при обмене не потеряются и будет история об каждой сторнировке.

(56)
Ты почему-то путаешь совершенно разные понятия - PK и uid.

(80)
В данном случае - не вижу смысла их разделять.

(79)
1. и 2. Звучат здраво. Так и было когда-то - решили уйти.
3. же - редактирование путем сторнировок в оперативном режиме - чревато геммороем.

Ты городишь костыли вокруг очевидного факта. Если ЕСТЬ документ ( как его не назови) то его рано или поздно кто то захочет изменить. Рано или поздно его захотят изменить двое людей.   И разрешать коллизии на уровне строк - абсолютно нормальный подход для любой вменяемой системы. Не нравится - откажись. Но присутствовать то это должно.

У 1С ноги растут из "одна база на одно рабочее место". Кто то будет с этим спорить?

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

(81)
Ну, когда что-то путаешь, действительно часто не видишь смысла разделять.

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

Кстати, для объекта - строки таб.части 1С хранит идентификатор строки.
Например, такой код даст ошибку:
   СтрокаТЧ1 = ТабличнаяЧасть1.Добавить();
   СтрокаТЧ2 = ТабличнаяЧасть1.Добавить();
   
   ТабличнаяЧасть1.Удалить(0);
   
   СтрокаТЧ1.Реквизит1 = 1;
   
Выполнение операции невозможно, так как строка была удалена.

Хотя строка с номером 1 существует.

(83) // Если подавляющему большинству нормальная распределенка вообще не впилась (они себе вообще её слабо представляют)

ГУРУ снизашел с небес и решил нам всем показать как должна работать НАСТОЯЩАЯ распределенка :) Не уходи только из ветки - пише еще! Есть хоть над чем поржать в понедельник.

(87)
Конкретно до тебя снисходить - дохлая затея.

Есть! Новый УникальныйИдентификатор

(86) ту путаешь - уид строки тут совершенно ни при чем. Просто переменная СтрокаТЧ1 которая ссылалась на конкретную область памяти все так же и ссылается туда. Но в той области после выполнения Удалить(0) уже совсем не то что было раньше. Короче - это основны программирования.