Текст из стандартных xp
Update RG165
 set SP168=Case When ABS(SP168+@p3)>999999999999.99 Then 999999999999.99 Else SP168+@p3 End
Но если у нас переполнение идет по - ( отрицательное число )
то в остатках по регистру получим бред. ( я  понимаю что ситуация маловероятная но тем не менее возможна)
кто что думает по этому поводу.
весь текст xp

Create procedure _1sp_RG165_Change(@per DATETIME, @p1 CHAR(9), @p2 CHAR(9), @p3 NUMERIC(14, 2)) AS
Set Nocount On
Update RG165
  set SP168=Case When ABS(SP168+@p3)>999999999999.99 Then 999999999999.99 Else SP168+@p3 End
  where PERIOD=@per AND SP167=@p1 AND SP2139=@p2
if @@ROWCOUNT=0
    insert into RG165 values(@per,@p1,@p2,@p3)
GO
 

Расслабся. Ты не глючишь.

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

Z1, ты не понял. Я хотел сказать, что результат в таблицах итогов 999999999999.99 ни чем не лучше , чем вообще любой другой результат если он отличается от правильного. Платформа это не контролирует, ни каких исключений твоя конфигурация не получает в любом случае. И поэтому на этот код ХП генерируемых платформой можно просто забить, т.к. толку от него нет никакого. Следовательно, ты как разработчик конфигурации должен закладывать такую размерность ресурсов чтобы ее всегда хватало.
А ты заложил недостаточную размерность ресурсов - в этом твоя ошибка.

Ну в общем-то ты прав. Только я не думаю что производительность выростет сколь-нибудь ощутимо, в тоже время изменение этих ХП требует определенного кода (в конфигурации или еще где-то), универсальный код не такой уж и простой получится. К тому же надо определяться с моментом когда его отработать.
Вобщем я бы оставил как есть.

Рискну дать стандартный совет по оптимизации.

Сначала сделай замеры. Перед оптимизацией. Выясни, какое именно место тормозит больше всего, и именно туда направь все свои усилия. Оптимизировать три дня процедуру, которая загружает сервер на 0.5% - довольно глупо.

Цитата:


Ага, только будут ли заметны эти улучшения? Я думаю нет. Тебе видимо пора про гибкие блокировки думать.

Z1 писал(а) 05. Ноября 2008 :: 10:17:

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

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

Дальше на тормозящий компьютер вешаешь мониторы производительности. Находишь тормозящую железку. Думаешь, можно ли тупо и дешево добавить производительности? Если можно, то добавляешь.

Если ты нашел тормозящую программу - смотришь, как ее можно оптимизировать, и можно ли. Для каждой тормозящей программы существуют свои способы профилирования. Для 1С - свои, для sql - свои.

Цитата:

Дело не в том, будет ли лучше или хуже. Дело в том, насколько эффективно ты тратишь деньги своего работодателя.

Одно дело сказать
"Вы потратили две моих месячных зарплаты на то, чтобы поднять производительность сервера на 0.7%"
и совсем другое -
"Вы потратили три моих месячных зарплаты и еще кучу бабок на апгрейд, но теперь наш сервер вообще не тормозит, и можно смело набрать еще 250 сотрудников, не опасаясь того, что он будет тормозить."