Деление на 0 #428538

Доброго времени суток, может кто поможет... В 1с предприятие - Торговля+склад, редакция 9.2 возникла такая ситуация когда открываю "Остатки ТМЦ" выбираю фирму, остатки, цены. При формировании выдает следующею ошибку, ПечКол = ПечКол / ТЗ.ПечЕд.Коэффициент; {Отчет.ОстаткиТМЦ.Форма.Модуль}: Деление на 0 Как можно исправить? С 1с знаком на уровне администратора. Спасибо!

HELP

У какой-то из единиц для какой-то номенклатуры кто-то указал в качестве коэффициента 0. Найти, у какой, исправить на что-то более естественное.

Или тупо печЕд не выбрана...

Не стоит так делать. От того, что отчёт выведется внешне пристойно - ошибка ведь никуда не исчезнет.

А шобы было красиво Попытка ПечКол = ПечКол / ТЗ.ПечЕд.Коэффициент;

С СокрЛП(ТЗ.ПечЕд) можешь извратиться так СокрЛП(ТЗ.ПечЕд)+" "+СокрЛП(ТЗ.ПечЕд.Владелец) Если прокатит

Ну и зачем эти извращения, замедляющие часто используемый отчёт непонятно ради какой цели?

глупый пользователь увидит, где не проставлен коэффициент единицы измерения, а сисадмин довольный пойдет домой. А программер, который это не предусмотрел получит двойку.

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

проще при записи единицы измерения проверить, что коэффициент заполнен )

а админу могу посоветовать вставить этот код с попыткой. Исправить ошибки, которые он сообщит, потом вернуть первоначальный код )

а насколько Попытка замедлит выполнение при выводе большого количества строк? имхается что более существенным будет скорость отрисовки готовой таблицы на экране...

можешь привести вычисления, насколько конструкция попытка - исключение затормозит выполнение сего отчета?

это все потому, что объекты и код манипуляции этими объектами никак с собой не связаны... длаешь как там еее эту.. инкапсуляцию!

опоздун! ;-)

пошел ставить опыт

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

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

Приятно удивлен таким активным форумом, завтра попробую все выше написанное и сообщу, что получилось т.к. у нас уже за полночь.

не ты код тот писал, что так вписываешься за оптимизацию?

никого не слушай и юзай то, что я написал тебе в и будет тебе счастье

А уборщицу или сантехника пользователи по этому поводу не дрючат? А почему?

патамушто уборщица скажет, что тяжелее швабры ничего не держала, а сантехник пошлет их на юг

Затем, что вываливание юзеру рантаймовых ошибок -- верх некошерности.

Можно так еще, для того, чтобы успокоился: Если ТЗ.ПечЕд.Коэффициент = 0 Тогда

+1 Простой код из 10 операторов показал, что использование Попытки замедляет выполнение примерно на 10%... так что от того что отчет формируется 60 минут, или 66 минут - разницы никакой... надо еще учесть что эти 10% - это при услвоии соотношения операторов Попытка к прочим операторам примерно 1/3.. так что на реальных отчетах, где всякие итоги считаются и порчая лабудень - заведомо меньший вклад будет... конечно если особые умники внутрь попытки не загонят сто тыщ мильенов операторов...

А! блин! дятел программист может вообще назомутать и ПечЕд не заполнить.. и чего - будем проверять все возможные варианты? я давно в критичных участках 1-2 оператора в попытку загоняю, когда не могу предусмотреть или времени нет защиту от дурака делать...

интересно, а что же у них в остатки пишется, если ТЗ.ПечЕд.Коэффициент=0

, 10% - это на самом деле довольно много. Расставь всего лишь 10 Попыток - и время выполнения удвоится. И пользователь-то - не один, тормозить он будет всех прочих (наблюдается в небольших конторах: бухгалтер строит отчёты - остальные тихо матерятся). А насчёт "дятел программист может нахомутать" - может. Но в таком случае надо исправить ошибки дятла-программиста, а не перегружать код лишними проверками. В речь шла о типовой Торговле, где стоит контроль на заполнение коэффициента ПриЗаписи единицы. Так что 0 там может возникнуть только "нештатным" способом. И, появившись раз - может воспроизводиться снова и снова, пока не будет исправлена ошибка, его порождающая (а она _не_ будет исправлена, пока её существование будет скрыто Попытками). И, как верно замечено в - эта ошибка скажется не только в отчёте (где её можно обработать таким способом), но и в куче других мест.

ход мысли ясен, мол сисадмин не лезь в код, а позови меня, я за бабосы все поправлю )))) Франч?

Разумеется, некошерно. Но в типовой, при штатной работе, такой ошибки не возникнет. Следовательно, надо не стремится к информативности сообщений пользователю (ему эти сообщения ничем особо не помогут), а искать причину, по которой появился 0 или единица оказалась не заполнена (есть ведь и такой вариант).

Нет, не франч. Тебя на подвиги тянет? Ляг, поспи - и всё пройдёт.

+ Или попробуй в типовой, работая как пользователь, записать единицу с коэффициентом 0.

например, на какие подвиги меня тянет?

насколько мне память не изменяет, в типовых переменную ПечЕд на печать выводят, а не делят и умножают )))

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

зануда?

+ елси не франч

Насчёт :

: +1000

Да, зануда. Предпочитаю находить ошибки и их исправлять, а не прятать голову в песок, делая вид, что их нет.

точно не зануда и не франч... наверно тот, про кого в сообщить написано )

а зачем там это:

Перем Описание - отставить!

С этим вопросом - к Нуралиеву.

Жесть! Наверно очень сильный флаг!

дык флаг у тебя Китайский или Российский?

Если так принципиально на Попытку Исключение реагируешь, то объясни мне зачем тебе повисшая на 60 сек. транзакция к базе данных в процедуре ПриЗаписи?

все, ответа не дождался, поехал на моце гонять... тяпница

В ОбработкеПроведения тоже предупреждения вешаешь?

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

А где ошибка в коде? В отчёте ОстаткиТМЦ? Или в том месте, где единица получила коэффициент 0 или была не задана? (Кстати, какой из вариантов имеет место быть? Предлагаемый код с Попыткой их не различает).

Сделать ТЗ.ПечЕд.Коэффициент отличным от нуля не предлагать! Конкурс продолжается.

!повтор эмм... то есть, в чем суть конкурса?

Найти самый извратный способ решения проблемы (пошло-банально-тривиальный способ одинэсина сама написала).

а побеждает, кто больше букв напрудит или, у кого проц сильнее нагреется?

Кто заставит юзеров проапгрейдить процы компутеров до йййй...елерон ХХХХХ терагерц и заработает откат от Интела :)

Ошибка в том, что при определенных данных отчет вываливается в RTE. Если данные некорректны, отчет должен внятно об этом сообщать, а не ругаться непонятными юзеру словами.

На самом деле, оператор попытки действительно занимает много времени, но никто не требует использовать этот оператор в самом цикле, так как исключение можно отловить и на самом верхнем уровне, а там оператор попытки будет исполняться только один раз! И действительно, сообщение пользователю должно выглядеть более позволяющим ему самому решить проблему своих кривых рук, нежели уповать на помощь такого же криворукого программиста. Кстати, а ТЗ.ПечЕд - это что ? Это же поле в какой-то таблице значений, и надо смотреть откуда оно заполняется.

: "ПриЗаписи" выполняется не в транзакции, ламер...

ну почему же...

: это не "ПриЗаписи" выполняется в транзакции, это накоженное принудительно включено в транзакцию - почувствуй разницу, Цугундер.. )))

а в чем же? Если у одного юзера ПриЗаписи у другого ПриЗаписи, они одновременно запишутся? Да?

ну тогда и ПриОткрытии - а то одновременно откроются...

: а ты к тому же и упрямый ламер... и лезешь с советами... не, нучо, характерно. приколись: в транзакции выполняется только проведение документов (транзакция на уровне движка)... ну и код, программно включаемый в транзакцию. ;)

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

Но транзакции и блокировки - это, вообще говоря, не одно и то же.

Вообще говоря - да (так как некоторые сервера SQL умеют выполнять несколько транзакций одновременно) - поэтому я и написал "мини-транзакция", чтобы не нарушать терминологию.

Общее у блокировок и транзакций - по сути, лишь то, что блокировка может служить механизмом обеспечения транзакции. Я не вижу смысла искусственно вводить некую новую терминологию, тем более, что и понятие транзакции, и понятие блокировки используются в 1С во вполне определённом смысле.

В 1С всё просто - блокировка объекта - это защита объекта от изменений. Транзакция - это гарантия правильного исполнения алгоритма чтения и изменения данных и исключение влияния других пользователей на этот алгоритм. 1С блокирует элемент справочника, если он открывается на редактирование или если мы явно вызываем установку блокировки. Но блокировка и захват файлов для выполнения записи - это совершенно другое действие, никак не связанное ни с блокировкой ни с транзакцией.

Транзакция - неделимая операция над данными. Остальное из этого вытекает.

А вложенные транзакции тогда что ?

"Внутри" себя транзакция не является, естественно, неделимой. С точки зрения "внешней" транзакции - вложенная транзакция является (неделимой) транзакцией. С точки зрения ещё более "внешней" - какие-такие вложенные транзакции?

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

В 1С транзакция - это внутренний флаг режима доступа к данным. Соответственно, можно пытаться установить этот флаг более одного раза (и никакой ошибки при этом не возникает), но и снимать его придётся столько же раз. При этом, отрабатывается только окончательное снятие флага (Зафиксировать или Отменить) в остальных случаях - только уменьшение счётчика.

"но и снимать его придётся столько же раз" - бред оф сивый кейбл.

А что тебе не нравится ? i=2/0; и видим, что Const.Проверка=1 !

для поиграться вложенными транзакциями: (пароль = семь семёрок). : ну не поддерживает она (семёрка) хоть ты наизнанку вывернись... ;)

Я знаю, что она не поддерживает. Точнее, поддерживается одна транзакция - остальные только "изображаются".

>> в типовой, при штатной работе, такой ошибки не возникнет. НЕправда!!. Возникает, хотя проверка на ПустоеЗначение(Коэффициент)=1 у элемента Единицы на месте. В двух разных местах ТиС поддерживаю, и в обоих пришлось это же место доработать