Имя: Пароль:
1C
1C 7.7
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
Не то обсуждаем.