напомните, плз, чем это может грозить, кроме невозможности использования  ПолучитьСтрокуПоНомеру() ?

вроде ничем.

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

в 8, те-же грабли.

Более ничем.

пиши напрямую в регистр

(2) да не особо тормозит, вроде.

(6) а ты поскроллируй тч

в скл
ПК = иддок,лайнНо. лайнНо- смолинт.

(7) всё нормуль, особых тормозов нет

ещё один минус - строки с номерами > 9999, которые при записи были расположены в конце, при последующем открытии дока безобразно-хаотично кучкуются в начале ТЧ с № строк 0.

в остальном, вроде, косяков не заметил

Нумерация строк в доках до 9999, соответственно получитьстрокупономеру не будет работать. И при тисе скорее всего будут ошибки лезть. Короче, работать можно, но лучше так не делать

Не при тисе, а при тии

(11) кто ж в здравом уме на больших базах ТиИ будет делать?

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

(13): нет.

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

(13) ТИИ ничего не регистрирует. Делал я когда-то документ корректирующий регистры в 7ке, он у меня работал и при свертке базы нетиповых семерок.

(15) Нет там номера строки уже.

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

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

я бы стрелял за такую организацию данных.  представляю сеюе счет фактуру для склада.

Имхо, делить надо на помельче

(20) ворон в парке иди стреляй. где ты увидел про накладную и сч/ф?

(20)Я экстраполировал:-)..  А что за док на 10 000 строк тгда?

(19) "Изначальные" - это какие? Имей в виду, что порядок строк не меняется автоматически, то есть если строка была 10384-ой, то она после записи документа хоть и получит номер 0, но останется на том же месте, а после (15) вновь станет 10384-ой.

(22) Инвентаризация, например.

(24)Инвент обычно по складу делается. Они там Пустыню Небраска арендовали?:-)

(25) А ты представь такой торговый отдел, где почти каждая штука товара - самостоятельная номенклатура! :-)))

(22) алкодекларация (будь она неладна)
(23) да нифига. можешь сама попробовать, если не веришь. ПолучитьСтрокуПоНомеру() ведёт себя непредсказуемо при кол-ве строк > 999

(26)Кажлая штука - это уже назывется Основное Средство. Не катит:-)

* при кол-ве строк > 9999, конечно

(29)Да не парься ты.  Дели на доки по 500 строк, заведи реквизит для объединениея в документе

(30) нафига этот изврат? всё замечательно работает, если не считать визуальных артефактов в виде перемещения хвостовой части в начало, и на которые всем плевать

(27) Да я пробовала уже, и всё работало, иначе бы я не стала тормозить открытие документа выгрузкой-загрузкой таблицы.
(28) Какое нафиг средство? Я про торговлю.

(31)  Это ты еще больших баз не видел. Тут иногда колдуешь над каждой транзакцией как раньше во времена асемблера над каждым байтом.

(32)А я про учет. Если объект учиттывается как единица по штучно - это ОС:-)

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

(31) Если все нулевые строки попадают в начало, значит ты сам где-то по дороге табличную часть сортируешь.

(32) 1. в общем случае не работает

(36) да что ты мне сказки рассказываешь. записал, вышел, зашёл - и вот они

(31) Тебя не хотел спрашивать, но: Конфа какая?

(39) когда-то была ТиСом

(34) И при чём тут ОС?

(36) Ты только до 99999 + 99999 научился создавать документы? Посмотри на принцип сортировки.

(41)Ладно. Проехали. :-)

(41) не буду же я тебе тут бухучет объяснять:-)

(32) и как же она в базу, в поля длинной 4-ре символа запишет номера, которые физически длиннее 4-ох значащих цифр?

(38) База DBF или SQL?

(46) dbf

(44) Конечно, нафиг нужен бухучёт там, где он нафиг не нужен?! :))
(45) Ты не понял. При открытии документа нужно делать (15).

(48) Блаженны верующие, ибо они утешатся (С) Библия

:-)
Ты  странно наплевательски кстати относишься к серьезным вещам, которых не понимаешь.

(48) Не взлетит :)

(47) Ну, не знаю, возможно, что-то ты упустил.
У меня был такой случай на документах инвентаризации, и там был очень важен порядок строк, поскольку между обычными строками с номенклатурой были строки вида "Стеллаж №237". То есть после строк с номером стеллажа шли строки с номенклатурой, затем следующий стеллаж и так до конца. Если бы там перемешивались стеллажи, то меня бы съели.

(49) Ты о чём это?

(52) Об основных средствах как понятии.

(50) У меня взлетало. И странно, что тут ещё какие-то сомнения возникают.

(51)за такую организацию сьесть надо

(53) Я "наплевательски" отношусь к основным средствам?!
Да я вообще их не касаюсь вообще-то.

(49)
ИМХО ты неправ. ОСы имеют много особенностей. И пообъектный учет - только одна из них. Ничего не мешает учитывать номенклатуру пообъектно с точки зрения бухгалтерского учета. Да и реальные задачи подобного учета (учет по серийным номерам к примеру) встречаются.

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

(55) Это исторически сложилось и в целом ничем не мешало.

(56)Оно и видно. Что "не касаешься" :-)

Ладно, я тебя тут не нанимался учить уму разуму:-)

(57) кстати, такими темпами придём, как раз, к пообъектному учёту водки
Водка с маркой №11223344
Водка с маркой №11223345
и т.д.

(61)
Реально сталкивался с таким пожеланием (пообъектный учет номенклатуры). Правда не делал :)

(58) Тем не менее, иногда это необходимо, иногда это имеет смысл. Конечно, при возможности я бы этого избегала, но в данном случае это было наилучшим вариантом.

(61)Кстати прими мои соболезнования. У нас тут пытались в прошлом году ввести алкоголь, лицензирование и учет акцизных марок.  Мы за полтора месяца все програмно накодили...   а потом у них не взлетело...  Сложная эта штука - торговля алкоголем

(63)колонку в тч добавить, не?

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

(65) Насколько я помню, в конце концов удалось людей к этому склонить.

(66) А зачем было делать лишний реквизит, когда для этого было вполне достаточно НомерСтроки? Только для того, чтобы немного быстрее открывался документ? Это роскошь. В том случае размер таблиц был более критичен, чем несколько секунд задержки при открытии большого документа.

(61) ИМХО к производителям-торговцам алкоголем нужно относиться как к наркодилерам.
Так что в данном случае госмашина действует верно. Ничего личного :)

(8) а зачем получать строку по номеру в 8?

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

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

(72) ого! Пошла речь о целесообразности в применении к документу, который никто никогда даже не просмотрит, я уж не говорю о том, что внимательно изучит эти самые более десяти тысяч строчек в нем. Не кажется ли тебе такая постановка несколько странной? Что касается размера базы, то вот эти самые таблицы влияют на размер базы, как правило, существенно меньше, чем таблицы с движениями

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

(74) Не совсем регламентный. Инвентаризация в отделе - теоретически таких (десятитысячных) документов могло быть не более пяти за год, на моей памяти их было всего штуки три за два года. Было бы глупо переделывать из-за этого работу со строками, да ещё и реквизит добавлять, который, кстати, здесь совершенно бы не помог, поскольку ПолучитьСтрокуПоНомеру всё равно было бы нельзя (а если строить работу не с ТЧ, а с ТЗ из ТЧ, то и добавлять реквизиты в документ нет нужды).