|
v7: Проблема Ожидание блокировки 1С 7.7 при смене сервера На Современный | ☑ | ||
---|---|---|---|---|
0
xSerj
11.10.13
✎
02:33
|
Новый сервер:
CPU = Два AMD Opteron 6380 2,8GHz (в Windows - 32 ядра). Mem = 32 Gb HDD = 4 SAS дисков, RAID 10 ? на контроллере LSI MR9271-4i, 1Gb Кэша. ОС: Windows Server 2003R2 sp2 Datacenter Edition 32 бит. Старый сервер: CPU = Два Intel Xeon 5030 2,66ГГц (в Windows - 8 ядер). Mem = 16 Gb HDD = Два ultra wide SCSI в зеркале. ОС: Windows Server 2003R2 sp2 Enterprise Edition 32бит. 1С: 7.7, релиз 25, dbf. Размер базы: 4 Gb. Пользователей: 56. Вход: Терминальный. ПРОБЛЕММА: На старом сервере пользователи работают с базой. Хоть и медленно, но уверенно. На новом: 1 user работает в 3 раза быстрее. 56 users - Регулярное "ожидание блокировки" работь хуже чем на старом. при том же дистрибутиве 1С и той же базе. В 1С используется: 1CPP.dll (2.0.2.1) для раскраски. Admin1C.dll (1.0.0.0) для таб Пользователей ROM-Mail.dll (1.3.1.0) Terminal Sleep от Romix ВОПРОСы: Существуют ли какие-то особенности Datacenter Edition, плохо согласующиеся с 1С 7.7 или доп. DLL? Или есть особые настройки сервера?.. Посоветуйте что-то, пока меня не заставили выкупить себе Новый сервер (8000$). |
|||
117
xSerj
12.10.13
✎
00:00
|
(99) NS. Пока все ушли ставил в win галочку "повышенная производительность" и снимал. Результат на одном и том же запросе не поменялся. 1-й вход 140 с, второй (от другого пользователя 1С, но тот же пользователь Win) 120 c.
Запрос 29 раз обращается к таблице РН, спр Клиентов, рег Затрат. Для стравнения результатов 29-и менеджеров по продаже за один и тот же период. |
|||
118
xSerj
12.10.13
✎
00:01
|
(116) Поддерживаю
|
|||
119
xSerj
12.10.13
✎
00:03
|
(111) Будем пробовать.
|
|||
120
xSerj
12.10.13
✎
00:27
|
(111) Спасибо, попробуем, но это развитие ускорения, а ведь на старом RAM диска нет.
|
|||
121
NS
12.10.13
✎
01:04
|
(117) это же кеширование записи, а не чтения.
|
|||
122
xSerj
12.10.13
✎
01:43
|
(121) Значит это отразится на работе, но не на отчетах?
|
|||
123
NS
12.10.13
✎
01:48
|
(122) У тебя же проблема с блокировкой. А она возникает во время проведения. При проведении записываются движения документа, и их запись ускорится. Так же ускорится создание временных файлов, но это как указано выше можно сделать при помощи темпов на RAM-диске.
|
|||
124
NS
12.10.13
✎
01:52
|
Вопрос еще какая батарейка. Рам, Флэш, или РАМ + Флэш.
|
|||
125
xSerj
12.10.13
✎
01:53
|
(123) "и их запись ускорится", а чтение с кэша будет?
|
|||
126
xSerj
12.10.13
✎
01:55
|
(124) Извини даже вопрос не понял. Но знаю что Физически есть батарейка. При кождом старте отчитывается о своем заряде. Пока 100%. (Серваку 2 месяца от покупки)
|
|||
127
NS
12.10.13
✎
01:55
|
(125) Чтение с Кэша в винде есть всегда, оно в параметрах не отключается, отключается только при сетевом доступе.
|
|||
128
NS
12.10.13
✎
01:56
|
(126) Речь про кеш на контролере.
|
|||
129
xSerj
12.10.13
✎
01:59
|
(128) Да
|
|||
130
NS
12.10.13
✎
02:03
|
(129) Что да? Там Флеш, ОЗУ, или то и другое?
Гиг там ОЗУ? Если Гиг ОЗУ, то рисковать и включать отложенную запись (максимальное ускорение) нет смысла, достаточно сквозной, простого кеширования записи. Если Гиг флеша, то отложенная запись даст ускорение, но немного повысит риски смерти базы после сбоя. |
|||
131
xSerj
12.10.13
✎
02:03
|
(127) База на D:\ в IG_trd
стандартные "D$", "Стандартный общий ресурс", имеют значение? |
|||
132
xSerj
12.10.13
✎
02:06
|
(130) Таких точностей я пока не знаю, но узнаю.
|
|||
133
NS
12.10.13
✎
02:06
|
(131) Имеет сам факт подключения сетевых, а не локальных в терминале пользователей.
|
|||
134
NS
12.10.13
✎
02:12
|
(131) При подключении второго (и последующего) пользователя к сетевой (не SQL!) базе 1С резко возрастает "торможение" 1С:Предприятие 7.7 при работе по сети. Причем, при отключении второго пользователя торможение сохраняется, до перезагрузки сервера. Это особенность Windows NT/2000 - система не умеет кэшировать (сохранять в памяти) файлы при совместной многопользовательской работе по сети. Проблема описана в статье на диске ИТС (от фирмы 1С).
http://kb.mista.ru/article.php?id=136 Это актуально и при работе в терминале. Если к устройству начнут подключаться сетевые пользователи, виндовое кеширование отключится. |
|||
135
NS
12.10.13
✎
02:15
|
Если убрать шары, то можно себя от этой неприятности гарантированно обезопасить.
|
|||
136
xSerj
12.10.13
✎
02:31
|
(134) "Если к устройству начнут подключаться сетевые пользователи" К диску D: нет. А другие шары на других дисках имеют значение?
На старом срв есть и шары к другим папкам и т. д. Но ведь работает... |
|||
137
NS
12.10.13
✎
02:34
|
(136) Не знаю.
|
|||
138
xSerj
12.10.13
✎
02:38
|
Уточняю, пока вспомнил, остальные шары (на старом срв) физически на других дисках...
|
|||
139
NS
12.10.13
✎
02:45
|
(138) Всё равно не знаю. Варианта три
1. Кеш отключается на физическом устройстве (Raid) 2. Кеш отключается на логическом устройстве - диске. 3. Кеш отключается для папок/файлов к которым произошло обращение по сети. |
|||
140
xSerj
12.10.13
✎
02:51
|
(139) бум гуглить...
|
|||
141
xSerj
12.10.13
✎
03:00
|
(139) По памяти, думаю к физ дивку или к объедененному диску в RAID. Во всяком случае на старом срв есть RAID и доп диски, они то и разшарены и на старом срв таки работают в 4-х базах 56 юзеров
|
|||
142
xSerj
12.10.13
✎
03:02
|
(139) Как минимум есть вариант проверить экспериментально. Отключим все шары с Raid миассива и посмотрим...
|
|||
143
VladZ
12.10.13
✎
08:10
|
(0) Я бы не стал 56 пользователей садить в DBF базу. Я бы перевел базу на SQL. Закупил три сервера: один под SQL, два под RDP.
Два под RDP исходя из следующих соображений: 1. Есть возможность "разруливать" нагрузку. В любом случае среди пользователей есть операторы, задача которых быстро внести информацию, есть пользователи, которые занимаются анализами: формируют отчеты пачками. Можно будет разрулить: операторов отдельно, аналитиков отдельно. 2. Надежность. Допустим у нас один сервер. И допустим он сломался. Вся фирма сидит и нервно курит. В случае двух серваков, при поломке одного из них, можно всех пользователей завести на один сервак. Да, нагрузка возрастет, но работать можно будет. В случае, если падает SQL - разворачиваем его на одном из оставшихся серваков. 3. Обслуживание серверов. В случае нескольких серверов есть возможность поочередного обслуживания. 4. Теперь почему SQL. Надежнее. Нет проблем с ожиданием, когда же база наконец-то переиндексируется. Плюс, появляются дополнительные "плюшки". |
|||
144
VladZ
12.10.13
✎
08:12
|
+143 Можно задействовать старый сервер. Если как есть - то под RDP. Можно чуток с дисковой покрутить и под SQL настроить.
|
|||
145
VladZ
12.10.13
✎
08:17
|
"Посоветуйте что-то, пока меня не заставили выкупить себе Новый сервер (8000$)." С чего это? Ты закупал или админ?
|
|||
146
viktor_vv
12.10.13
✎
08:20
|
Насчет отключения кешированя при сетевом доступе, думается мне там идет не отключение кеша дисков в целом кеша диска, а не кешируются в памяти именно файлы, которые по сети открываются. То есть если к базе по сети не подрубаются, то все нормально, остальные шары не влияют на это.
|
|||
147
ЧеловекДуши
12.10.13
✎
10:23
|
(0) >>>На новом:
1 user работает в 3 раза быстрее. Ну да, ну да попробуй начать работать 10-тью или 20-тью пользователями :)))) Наивный |
|||
148
ЧеловекДуши
12.10.13
✎
10:24
|
(146) Да ему нечего не поможет :)
|
|||
149
hhhh
12.10.13
✎
10:43
|
(93) конечно виноват. Ну админ ясно - тупой, но вы-то? Должны понимать, что серверы практически одинаковые. На старом естественно 7.7 будет работать в 2 раза быстрее, она писалась 15 лет назад.
|
|||
150
GStiv
13.10.13
✎
09:28
|
Raid10 это под базу или система и база, скорее всего диск по lun порезали. Попробуйте базу положить на отдельные диски от системы
|
|||
151
bushd
13.10.13
✎
09:47
|
(150) + 100500 такая же мысля пришла. Базу сложить на быстрый независимый носитель. А так правильно заметили узкое место 77 не ликвидируется увеличением ядер.
P.S. Эмоции - серваки на ксеннонах - всегда меня радовали... |
|||
152
Alexor
13.10.13
✎
16:35
|
(143) Если не ошибаюсь.
Сейчас проблема 7-ку до скуля докупить. Да и сам скуль вроде только 2005 на клюшках возможен, а его не купить. |
|||
153
Кип Калм
13.10.13
✎
18:02
|
(152) Купит 7.7 для скл не проблема, 7.7 работает даже на скл 2014.
|
|||
154
Злопчинский
13.10.13
✎
21:53
|
(153) обозначь, кто продает с реганкетой и лицензионным договором? купить на вторичном рынке скульный движок - вообщем можно, но вот есть ли у тебя при этом сублицензионный договора и реганкета?
|
|||
155
NS
13.10.13
✎
21:59
|
(154) Прайс на сайте 1С не является публичной оффертой?
http://www.1c.ru/rus/partners/goodlist.jsp?parentKod=1CV77&kod=1CV77 |
|||
156
viktor_vv
13.10.13
✎
22:38
|
(153) Насчет скл 2014 меня терзают смутные сомнения. Штатно это скл 2000 , с более поздними подружить, это не совсем штатные методы.
|
|||
157
Dolly_EV
14.10.13
✎
15:59
|
"8000$" - как-то дорого для озвученной конфиги?? не?
Переписать конфу (узкие места) на прямые запросы не предлагать? - тогда при таком раскладе "Размер базы: 4 Gb. Пользователей: 56. Вход: Терминальный. " - достаточно будет и половины старого сервака, чтобы забыть про блокировки а вообще - обсуждалось уже 100500 раз все это: дело не в железе, а в кривом коде конфы. |
|||
158
xSerj
15.10.13
✎
01:45
|
(157) Вопрос то не в том как оптимизировать код
ВОПРОС: ПОЧЕМУ НА НОВОМ ЖЕЛЕЗЕ ОДНА И ТА ЖЕ БАЗА, НА ТОМ ЖЕ ПО РАБОТАЕТ ХУЖЕ, ЧЕМ НА СТАРОМ? |
|||
159
xSerj
15.10.13
✎
01:48
|
(139) Спасибо, ты лучше других обяснил куда смотреть...
Установил на контролере такие параметры (Админ выставил) Strip Size = 256 KB VD has Emulated PD = No Span Depth = 2 Number of Drives Per Span = 2 Write Cache(initial setting) = WriteThrough Disk Cache Policy = Enabled Encryption = None Data Protection = Disabled Active Operations = None Exposed to OS = Yes Creation Date = 15-06-2013 Creation Time = 04:41:31 PM Emulation type = None Сегодняшний тест прошел на ура, но тест длился 20 мин. Планируем полный тест, тогда отпишусь... |
|||
160
xSerj
15.10.13
✎
01:49
|
может кто скажет новые замечания по настройкам контролера?..
|
|||
161
xSerj
15.10.13
✎
01:52
|
Сегодня за 20 мин. работали отчеты как за час на текущем (старом) сервере. При этом блокировок небыло даже без Terminal Sleep
|
|||
162
xSerj
15.10.13
✎
01:54
|
(152) Что за проблема. Все юзают не лицензионное ПО. Поставлю любое, а пока читай пост № 158
|
|||
163
xSerj
15.10.13
✎
02:34
|
(146) От подключения по локале отказались более чем 10лет тому
|
|||
164
xSerj
15.10.13
✎
02:37
|
(137) Еще раз благодарочка!!!!!!!!!!!!!!
Ты хоть и не решил где у нас проблема, но лучше других обяснил, где копать... |
|||
165
Bigbro
15.10.13
✎
07:31
|
потестить очередь диска вроде предлагали, ответа я не увидел. посмотри и другие счетчики, по процентам попадания в кеш на чтение и на запись например.
|
|||
166
viktor_vv
15.10.13
✎
09:28
|
(159) Вот это
Write Cache(initial setting) = WriteThrough это сквозная запись. Попробуйте WriteBack - отложенную запись, должно быть быстрее, контроллер более эффективно очередь записи может построить. |
|||
167
viktor_vv
15.10.13
✎
09:31
|
(166)+ Насчет рисков из (130) думаю можно сильно не беспокоится, с батарейкой все нормально должно быть, причем если заряд батарейки опустится ниже некоторого критического уровня, то контроллер автоматом должен отключить отложенную запись.
|
|||
168
ЧессМастер
15.10.13
✎
09:49
|
(0) а почему скуль не используете ?
|
|||
169
xSerj
15.10.13
✎
20:32
|
(166) А кто даст гарантию, что отложенную запись будут читать другие юзеры, а не с харда? Боимся
|
|||
170
NS
15.10.13
✎
20:35
|
(169) В смысле? Это совершенно безопасная опция в случае наличия батарейки.
|
|||
171
xSerj
15.10.13
✎
20:35
|
(168) Вопрос не в скуле. Кроме того самый частый запрос рег.Остаток(Товар,Склад). Он на скуле работает в разы медленнее чем да ДБФ. Тестировал не раз. Другие отчеты и правда быстрее на скуле. Но ...
|
|||
172
xSerj
15.10.13
✎
20:37
|
(130) У нас DDR+ батарейка. Сегодня узнал.
|
|||
173
NS
15.10.13
✎
20:39
|
В винде, ставить отложенную запись - небезопасно, если винда ляжет это грозит потерей данных и смертью базы.
На рейде, если есть батарейка, опцию нужно включать обязательно. (172) Тем более опцию нужно обязательно включить, а в винде тогда можно оставить простое кеширование записи, без самой нижней галки. |
|||
174
viktor_vv
15.10.13
✎
20:41
|
(172) Ну это стандартный вариант. Насчет (169), никто там ничего не будет читать лишнего или другого, это отложенная запись только для контролера, для пользователя и ПО это обычная запись на диск.
|
|||
175
NS
15.10.13
✎
20:44
|
(171) Можно даже не вникая что в коде, сразу сказать что нужно переписывать. У вас слишком маленькая база чтоб тормозило.
|
|||
176
viktor_vv
15.10.13
✎
20:52
|
(175)+1. Я даже думаю, что там можно и штатными средствами нормально сделать, без извратов с прямыми запросами.
Сильно смутил "за 20 мин. работали отчеты как за час на текущем (старом) сервере" меня б наверное уже порвали на куски :)), если б отчет формировался час. |
|||
177
Z1
15.10.13
✎
21:04
|
(171) не верю.
тесты у Вас сомнительные. не может рег.Остаток(Товар,Склад) считаться быстрее под dbf чем под ms sql. (как бы чем больше нагрузка на базу тем больше ms sql будет выигрывать ) хоть бери остаток на та хоть на позицию документа на одной и той же базе sql обгонит dbf. ну как бы мое условие верно если sql сервер правильно настроен. Плюс если еще и оптимизировать расчет Остатка основываясь на конкретики задачи то выигрыш будет еще больше. |
|||
178
viktor_vv
15.10.13
✎
21:11
|
(177) Тоже было такое, таки в дбф быстрее. Я правда детальные тесты не делал, но одну базу перевел без предварительного тестирования на скуль, больше одного дня не выдержали :). По замерам производительности в отладчике, таки Рег.Остаток() тормозил.
Плюнул, не стал заморачиваться вернул взад, для 10 пользователей, в моем случае, сомнительное удовольствие мудохаться со скулем. |
|||
179
Z1
15.10.13
✎
21:27
|
(178) если ты востанавливаешь последовательность документов
или перепроводишь документы за полгода и сравниваешь работу этого теста в целом dbf и sql при работе одного пользователя это как бы один вариант то в силу тех или иных причин dbf база может быть быстрее. а если просто сравнивать вычисление Рег.Остаток(Товар, Склад) то и в том и в другом случае у тебя идет вычисление по индексу и Вы утверждаете что индекс в dbf лучше организован чем индекс в ms sql и вычисление по индексу dbf будет быстрее чем по индексу sql? (178) Опять же простота установки ms sql вовсе не означает что сервер ms sql правильно установлен и оптимально настроен. |
|||
180
viktor_vv
15.10.13
✎
21:33
|
(179) Не, перепроведения не было. Тормозили списки где в формулах были Рег.Остаток().
2. Поэтому и не стал заморачиваться со скулем, тем более простора для маневра особо не было, ни в плане ресурсов на той же машине где терминал, ни в плане выноса скуля на отдельную машину. |
|||
181
viktor_vv
15.10.13
✎
21:33
|
(180)+ 2 - это к вопросу правильной и оптимальной настройки скуля.
|
|||
182
Z1
15.10.13
✎
21:39
|
(180) В 171 утверждается что
вычисление Рег.Остаток(Товар, Склад) быстрее в dbf чем в sql и как ты предполается вычисление по одному товару и одному складу. никакого упоминания о списках в 171 нет. (180) Я как бы не говорю что ты сделал неправильный выбор формата базы для своей базы для 10 пользователей, а говорю что высказывание 171 неверное. |
|||
183
viktor_vv
15.10.13
✎
21:47
|
(182) Про списки имел ввиду. В форме списка справочника текстовое поле с формулой Рег.Остаток(ТекущийТовар,НекоторыйСклад).
Я может после выходных ради интереса потестирую одну и ту же базу в разных форматах. |
|||
184
xSerj
16.10.13
✎
00:56
|
(176) Обясняю, у меня одельно идет хронометраж отчетов. Кто когда и какой запуска, и сколько времени поратил формирование отчета. За 20 мин. на новом сервере потратили 904 с. за тот же день на старом сервере 17000. 17000/8/3(20мин 1/3 от часа)=708. Добавим разницу в процессорах и их времени получится за 20 мин как за час
|
|||
185
xSerj
16.10.13
✎
01:06
|
(177) Я же писал, что результат не в пользу скуля
|
|||
186
aka MIK
16.10.13
✎
01:07
|
(171) А ты бы попробовал вначале, а потом говорил что вопрос не в скуле. Ля делов то - на полчаса перегрузить dbf в sql!
И по запросу Рег.Остаток(Товар, Склад) - результат скорости выполнения запроса может в разы отличаться в зависимости от того склад в начале или товар |
|||
187
aka MIK
16.10.13
✎
01:09
|
Сравнивает блин палку копалку с новой версией плаки копалки и удивляется, почему старая лучше новой - а хер его знает, все на тракторах давно пашут
|
|||
188
viktor_vv
16.10.13
✎
01:33
|
(186) Чего б ему отличаться от порядка измерений, если в таблице итогов кластерный индекс по Период + все измерения . Это к скорости Рег.Остаток().
|
|||
189
viktor_vv
16.10.13
✎
01:51
|
(184) Теперь понятнее.
отя до конца не понятна формула учета разницы в процессорах, и нафига ее учитывать, ну да ладно. |
|||
190
КонецЦикла
16.10.13
✎
03:27
|
(176) Я когда-то видел отчет, который формировал документы, а потом использовал их данные
Воистину, неисповедимы пути одинэснегов... |
|||
191
xSerj
16.10.13
✎
03:41
|
(189) Один и тот же очет. когда 1 на 1 с компом результат в 2-3 раа в +
|
|||
192
xSerj
16.10.13
✎
03:42
|
(190) а клиентов?
|
|||
193
xSerj
16.10.13
✎
03:45
|
(183) все промто тест типа перебор номенклатуры и если негруппа получить остаток. все
|
|||
194
Salimbek
16.10.13
✎
10:04
|
(1930 В стандарте работа в ДБФ быстрее чем в СКЛ, если в СКЛ переписать получение остатков на прямой запрос через 1C++ и ODBC, то станет практически поровну
|
|||
195
Bigbro
16.10.13
✎
10:42
|
если тупо перебор - так и есть быстрее работает перебор в дбф.
|
|||
196
viktor_vv
16.10.13
✎
10:45
|
(195) Вовпрос не про перебор, а про скорость работы метода Рег.Остаток() в скуле и дбф. Про перебор было только как способ сравнить скорость работы метода.
|
|||
197
viktor_vv
16.10.13
✎
10:48
|
(194) А с чем связано различие в скорости ?
Посмотрел в профайлере, Рег.Остаток() через вызов хранимки сделано. Выше накладные расходы получаются на вызов хранимки? |
|||
198
Salimbek
16.10.13
✎
12:26
|
(197) ну там не только это же... т.е. если использовать только вызов хранимки и обработку результата, то может и быстро было бы, но нет ли у 1С-ки других "накладных" расходов?
|
|||
199
NS
16.10.13
✎
12:33
|
Штатно, кэшированием, получение остатков ускоряется во многие-многие разы.
|
|||
200
viktor_vv
16.10.13
✎
12:52
|
(198) Так в том-то и дело, что хранимка у них с многими телодвижениями вызывается.
Сравнил с подготовленным запросом 1С++, там вроде как тоже хранимка, но вызывается как-то попроще. И выполнитьСкалярный на подготовленном запросе раза в два быстрее, чем Рег.Остаток(). |
|||
201
viktor_vv
16.10.13
✎
12:59
|
(200) Вот выполнение скалярного запроса
exec sp_execute 12, ' BJ3 ', ' 15TF ' а вот рег.Остаток() declare P1 numeric(12,3) set P1=NULL declare @P2 numeric(12,3) set @P2=NULL declare @P3 numeric(11,2) set @P3=NULL exec _1sp_RG5272_Select 'Oct 1 2013 12:00AM', ' BJ3 ', ' 15TF ', P1 output, @P2 output, @P3 output select P1, @P2, @P3 Ну и сама _1sp_RG5272_Select Create procedure _1sp_RG1051_Select(@per DATETIME, @p1 CHAR(9), @p2 CHAR(9), @p3 CHAR(9), @p4 CHAR(9), @p5 NUMERIC(12, 3) OUTPUT, @p6 NUMERIC(12, 3) OUTPUT, @p7 NUMERIC(11, 2) OUTPUT, @p8 NUMERIC(11, 2) OUTPUT, @p9 NUMERIC(11, 2) OUTPUT) AS Select @p5=SP1055,@p6=SP1056,@p7=SP1057,@p8=SP1058,@p9=SP1059 from RG1051 where PERIOD=@per AND SP1855=@p1 AND SP1053=@p2 AND SP1052=@p3 AND SP1054=@p4 GO Я в этих материях не силен, поэтому и хотелось бы таки понять в чем прикол. |
|||
202
viktor_vv
16.10.13
✎
13:03
|
(201) + Текст процедуры от другого регистра, промахнулся, но смысл тот же.
|
|||
203
Ёпрст
16.10.13
✎
13:04
|
(194)А если в дбф переписать на прямой запрос с условием попадания в индекс..то тут и скуль не обгонит
:)) |
|||
204
NS
16.10.13
✎
13:06
|
(203) см. (199), и ничего переписывать не надо.
|
|||
205
NS
16.10.13
✎
13:18
|
И небольшой трюк под SQL, увеличивающий скорость в разы.
ВремОстаткиТМЦ.УстановитьЗначениеФильтра("Склад",Константа.ОсновнойСклад,1); ВремОстаткиТМЦ.УстановитьЗначениеФильтра("Номенклатура", ТекНоменклатура,1); ВремОстаткиТМЦ.ВыгрузитьИтоги(ВремТаблОстатки,1,1); ТекОстатки = ВремТаблОстатки.Итог("Количество"); |
|||
206
NS
16.10.13
✎
13:20
|
Только не понял почему у меня в третьей строчке оба параметра в единицу.
|
|||
207
viktor_vv
16.10.13
✎
14:11
|
(206) <ВклФильтр> - необязательный параметр. Число: 1 - в получаемую таблицу включаются измерения, закрепленные фильтром ; 0 - не включаются. Значение по умолчанию - 0.
<Очищать> - необязательный параметр. Число: 1 - перед выгрузкой таблица значений очищается; 0 - не очищается. Значение по умолчанию - 1. Так что второй параметр можно в 0 ставить. |
|||
208
viktor_vv
16.10.13
✎
14:12
|
(207) Да и третий параметр можно не указывать.
|
|||
209
NS
16.10.13
✎
14:12
|
(207) Я знаю.
(208) ? |
|||
210
viktor_vv
16.10.13
✎
14:16
|
(209) Третий (очищать) он по умолчанию и так 1 будет.
|
|||
211
viktor_vv
16.10.13
✎
14:16
|
Или я не понял вопрос в (206).
|
|||
212
NS
16.10.13
✎
14:25
|
(211) Я не понял зачем у меня стоят единицы. Но я отлично знаю что делают эти параметры.
|
|||
213
NS
16.10.13
✎
14:26
|
(210) Это новая парадигма программирования? Обязательно не указывать параметры по-умолчанию?
|
|||
214
viktor_vv
16.10.13
✎
14:35
|
(213) Да нет.
Я таки не могу понять в чем вопрос. Как бы из описания параметров можно понять зачем установлены те или иные значения. Конкретно к куску кода из (205) второй параметр можно в 0 ставить, так как в этом коде нет обращений к колокнам измерений в ВремОстаткиТМЦ. Зачем там 1 стоит я не знаю. Может дальше в коде есть обращения к колокнам измерений в ВремОстаткиТМЦ, ХЗ. |
|||
215
NS
16.10.13
✎
14:41
|
(214) Нафига к ним обращаться, если и так известно что там?
|
|||
216
NS
16.10.13
✎
14:41
|
Не то обсуждаем.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |