Имя: Пароль:
1C
1C 7.7
v7: В ТЧ документа КоличествоСтрок() > 10000
0 andrewks
 
18.09.12
20:09
напомните, плз, чем это может грозить, кроме невозможности использования  ПолучитьСтрокуПоНомеру() ?
1 Lama12
 
18.09.12
20:12
вроде ничем.
2 Чарльз Треч
 
18.09.12
20:12
Привязаться в движении к номеру строки не выйдет да и заметно тормозить будет при сохранении документа.
3 Lama12
 
18.09.12
20:12
в 8, те-же грабли.
4 GreyK
 
18.09.12
20:12
Более ничем.
5 aleks-id
 
18.09.12
20:13
пиши напрямую в регистр
6 andrewks
 
18.09.12
20:13
(2) да не особо тормозит, вроде.
7 aleks-id
 
18.09.12
20:17
(6) а ты поскроллируй тч
8 МихаилМ
 
18.09.12
20:24
в скл
ПК = иддок,лайнНо. лайнНо- смолинт.
9 andrewks
 
18.09.12
20:25
(7) всё нормуль, особых тормозов нет
10 andrewks
 
18.09.12
20:31
ещё один минус - строки с номерами > 9999, которые при записи были расположены в конце, при последующем открытии дока безобразно-хаотично кучкуются в начале ТЧ с № строк 0.

в остальном, вроде, косяков не заметил
11 Сияющий Асинхраль
 
18.09.12
20:33
Нумерация строк в доках до 9999, соответственно получитьстрокупономеру не будет работать. И при тисе скорее всего будут ошибки лезть. Короче, работать можно, но лучше так не делать
12 Сияющий Асинхраль
 
18.09.12
20:36
Не при тисе, а при тии
13 andrewks
 
18.09.12
20:37
(11) кто ж в здравом уме на больших базах ТиИ будет делать?

"но лучше так не делать" куды ж деваться? разбивать больно геморно.
14 Cthulhu
 
18.09.12
20:54
(13): нет.
15 Nirvana
 
18.09.12
20:58
ПолучитьСтрокуПоНомеру() будет работать, если перед этим выгрузить табличную часть в таблицу значений и загрузить обратно.
16 GreyK
 
18.09.12
21:02
(13) ТИИ ничего не регистрирует. Делал я когда-то документ корректирующий регистры в 7ке, он у меня работал и при свертке базы нетиповых семерок.
17 GreyK
 
18.09.12
21:08
(15) Нет там номера строки уже.
18 Nirvana
 
18.09.12
21:20
(17) При загрузке табличной части строки перенумеруются, и будут правильные номера.
19 andrewks
 
18.09.12
21:25
(18) правильные (изначальные) уже не будут. так что пофиг. тем более, что в данном случае порядок строк не важен. а через перебор строк всё работает корректно и так
20 Рэйв
 
18.09.12
21:28
я бы стрелял за такую организацию данных.  представляю сеюе счет фактуру для склада.

Имхо, делить надо на помельче
21 andrewks
 
18.09.12
21:30
(20) ворон в парке иди стреляй. где ты увидел про накладную и сч/ф?
22 Рэйв
 
18.09.12
21:32
(20)Я экстраполировал:-)..  А что за док на 10 000 строк тгда?
23 Nirvana
 
18.09.12
21:32
(19) "Изначальные" - это какие? Имей в виду, что порядок строк не меняется автоматически, то есть если строка была 10384-ой, то она после записи документа хоть и получит номер 0, но останется на том же месте, а после (15) вновь станет 10384-ой.
24 Nirvana
 
18.09.12
21:33
(22) Инвентаризация, например.
25 Рэйв
 
18.09.12
21:34
(24)Инвент обычно по складу делается. Они там Пустыню Небраска арендовали?:-)
26 Nirvana
 
18.09.12
21:36
(25) А ты представь такой торговый отдел, где почти каждая штука товара - самостоятельная номенклатура! :-)))
27 andrewks
 
18.09.12
21:37
(22) алкодекларация (будь она неладна)
(23) да нифига. можешь сама попробовать, если не веришь. ПолучитьСтрокуПоНомеру() ведёт себя непредсказуемо при кол-ве строк > 999
28 Рэйв
 
18.09.12
21:37
(26)Кажлая штука - это уже назывется Основное Средство. Не катит:-)
29 andrewks
 
18.09.12
21:38
* при кол-ве строк > 9999, конечно
30 Рэйв
 
18.09.12
21:41
(29)Да не парься ты.  Дели на доки по 500 строк, заведи реквизит для объединениея в документе
31 andrewks
 
18.09.12
21:43
(30) нафига этот изврат? всё замечательно работает, если не считать визуальных артефактов в виде перемещения хвостовой части в начало, и на которые всем плевать
32 Nirvana
 
18.09.12
21:45
(27) Да я пробовала уже, и всё работало, иначе бы я не стала тормозить открытие документа выгрузкой-загрузкой таблицы.
(28) Какое нафиг средство? Я про торговлю.
33 Рэйв
 
18.09.12
21:46
(31)  Это ты еще больших баз не видел. Тут иногда колдуешь над каждой транзакцией как раньше во времена асемблера над каждым байтом.
34 Рэйв
 
18.09.12
21:46
(32)А я про учет. Если объект учиттывается как единица по штучно - это ОС:-)
35 Сияющий Асинхраль
 
18.09.12
21:47
Я, когда столкнулся с такими большими доками (даже два раза) один переделал под ограничение в 9999, а другой вообще в справочник. А тии я таки делал на большой базе - ругалась она на строки больше 9999, пыталась исправить и не могла
36 Nirvana
 
18.09.12
21:48
(31) Если все нулевые строки попадают в начало, значит ты сам где-то по дороге табличную часть сортируешь.
37 andrewks
 
18.09.12
21:48
(32) 1. в общем случае не работает
38 andrewks
 
18.09.12
21:48
(36) да что ты мне сказки рассказываешь. записал, вышел, зашёл - и вот они
39 GreyK
 
18.09.12
21:48
(31) Тебя не хотел спрашивать, но: Конфа какая?
40 andrewks
 
18.09.12
21:49
(39) когда-то была ТиСом
41 Nirvana
 
18.09.12
21:51
(34) И при чём тут ОС?
42 GreyK
 
18.09.12
21:51
(36) Ты только до 99999 + 99999 научился создавать документы? Посмотри на принцип сортировки.
43 Рэйв
 
18.09.12
21:52
(41)Ладно. Проехали. :-)
44 Рэйв
 
18.09.12
21:52
(41) не буду же я тебе тут бухучет объяснять:-)
45 Сияющий Асинхраль
 
18.09.12
21:53
(32) и как же она в базу, в поля длинной 4-ре символа запишет номера, которые физически длиннее 4-ох значащих цифр?
46 Nirvana
 
18.09.12
21:54
(38) База DBF или SQL?
47 andrewks
 
18.09.12
21:54
(46) dbf
48 Nirvana
 
18.09.12
21:56
(44) Конечно, нафиг нужен бухучёт там, где он нафиг не нужен?! :))
(45) Ты не понял. При открытии документа нужно делать (15).
49 Рэйв
 
18.09.12
21:58
(48) Блаженны верующие, ибо они утешатся (С) Библия

:-)
Ты  странно наплевательски кстати относишься к серьезным вещам, которых не понимаешь.
50 GreyK
 
18.09.12
21:58
(48) Не взлетит :)
51 Nirvana
 
18.09.12
21:59
(47) Ну, не знаю, возможно, что-то ты упустил.
У меня был такой случай на документах инвентаризации, и там был очень важен порядок строк, поскольку между обычными строками с номенклатурой были строки вида "Стеллаж №237". То есть после строк с номером стеллажа шли строки с номенклатурой, затем следующий стеллаж и так до конца. Если бы там перемешивались стеллажи, то меня бы съели.
52 Nirvana
 
18.09.12
21:59
(49) Ты о чём это?
53 Рэйв
 
18.09.12
22:00
(52) Об основных средствах как понятии.
54 Nirvana
 
18.09.12
22:01
(50) У меня взлетало. И странно, что тут ещё какие-то сомнения возникают.
55 kotletka
 
18.09.12
22:01
(51)за такую организацию сьесть надо
56 Nirvana
 
18.09.12
22:02
(53) Я "наплевательски" отношусь к основным средствам?!
Да я вообще их не касаюсь вообще-то.
57 Classic
 
18.09.12
22:02
(49)
ИМХО ты неправ. ОСы имеют много особенностей. И пообъектный учет - только одна из них. Ничего не мешает учитывать номенклатуру пообъектно с точки зрения бухгалтерского учета. Да и реальные задачи подобного учета (учет по серийным номерам к примеру) встречаются.
58 Сияющий Асинхраль
 
18.09.12
22:03
(48) без обид, но изменение дока при каждом открытии - это хуже, чем где ни попадя ставить метки. Это когда я молодежь обучал семерке на одном из первых же занятий говорил, так что не учи таким вещам
59 Nirvana
 
18.09.12
22:03
(55) Это исторически сложилось и в целом ничем не мешало.
60 Рэйв
 
18.09.12
22:03
(56)Оно и видно. Что "не касаешься" :-)

Ладно, я тебя тут не нанимался учить уму разуму:-)
61 andrewks
 
18.09.12
22:04
(57) кстати, такими темпами придём, как раз, к пообъектному учёту водки
Водка с маркой №11223344
Водка с маркой №11223345
и т.д.
62 Classic
 
18.09.12
22:05
(61)
Реально сталкивался с таким пожеланием (пообъектный учет номенклатуры). Правда не делал :)
63 Nirvana
 
18.09.12
22:06
(58) Тем не менее, иногда это необходимо, иногда это имеет смысл. Конечно, при возможности я бы этого избегала, но в данном случае это было наилучшим вариантом.
64 Рэйв
 
18.09.12
22:06
(61)Кстати прими мои соболезнования. У нас тут пытались в прошлом году ввести алкоголь, лицензирование и учет акцизных марок.  Мы за полтора месяца все програмно накодили...   а потом у них не взлетело...  Сложная эта штука - торговля алкоголем
65 kotletka
 
18.09.12
22:07
(63)колонку в тч добавить, не?
66 Сияющий Асинхраль
 
18.09.12
22:13
(63) не было это лучшим вариантом, имхо, худшим было. Лучший - вообще не делать такого. А если уж влом отказываться, то можно было добавить лишнюю колонку для ручной нумерации
67 Nirvana
 
18.09.12
22:20
(65) Насколько я помню, в конце концов удалось людей к этому склонить.
68 Nirvana
 
18.09.12
22:28
(66) А зачем было делать лишний реквизит, когда для этого было вполне достаточно НомерСтроки? Только для того, чтобы немного быстрее открывался документ? Это роскошь. В том случае размер таблиц был более критичен, чем несколько секунд задержки при открытии большого документа.
69 Фокусник
 
18.09.12
23:27
(61) ИМХО к производителям-торговцам алкоголем нужно относиться как к наркодилерам.
Так что в данном случае госмашина действует верно. Ничего личного :)
70 Шифровальщик2012
 
18.09.12
23:28
(8) а зачем получать строку по номеру в 8?
71 Сияющий Асинхраль
 
18.09.12
23:43
(68) зачем - уже было сказано ранее: модификация дока при каждом открытии это мягко говоря, очень дурной тон. Скажу по-другому: если твоими стараниями док работает так, что при закрытии дока пользователю задается вопрос на сохранение дока, при том, что пользователь док не менял, то тебе еще учиться и учиться программить на 1с. Без обид на сказанное
72 Nirvana
 
19.09.12
00:00
(71) Ну, слушай, если ты стал бы увеличивать и без того здоровую базу на целый реквизит табличной части только ради того, чтобы избежать вопроса на сохранение при закрытии некоторых документов одного вида, то это, скорее, тебе следует учиться - но не программировать на 1С, а простому здравомыслию. Рассуждать о прикладных решениях на уровне "это дурной тон" - это просто несерьёзно. Существуют критерии целесообразности, при которых сопоставляется, что будет получено при конкретной реализации, а что будет потеряно. Если бы все эти издержки, о которых ты говоришь, имели бы большое значение в том конкретном случае, то и решение было бы иным.
73 Сияющий Асинхраль
 
19.09.12
02:14
(72) ого! Пошла речь о целесообразности в применении к документу, который никто никогда даже не просмотрит, я уж не говорю о том, что внимательно изучит эти самые более десяти тысяч строчек в нем. Не кажется ли тебе такая постановка несколько странной? Что касается размера базы, то вот эти самые таблицы влияют на размер базы, как правило, существенно меньше, чем таблицы с движениями
74 Сияющий Асинхраль
 
19.09.12
02:25
И опять таки размер как таковой не критичен вообще. Для дбф критичен размер конкретного файла, но даже там обычно движения занимают места гораздо больше, чем табличные части. Тем более, что, если зашла речь о десяти тысячах строчек, то документ явно относиться к разряду регламентных, т.е вводимых не чаще пары раз в месяц, а не по пять-шесть сотен в день
75 Nirvana
 
20.09.12
20:55
(74) Не совсем регламентный. Инвентаризация в отделе - теоретически таких (десятитысячных) документов могло быть не более пяти за год, на моей памяти их было всего штуки три за два года. Было бы глупо переделывать из-за этого работу со строками, да ещё и реквизит добавлять, который, кстати, здесь совершенно бы не помог, поскольку ПолучитьСтрокуПоНомеру всё равно было бы нельзя (а если строить работу не с ТЧ, а с ТЗ из ТЧ, то и добавлять реквизиты в документ нет нужды).