VALIDATE во временных таблицах ...

[romeo]

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

[Yoil]

romeo, а можно более внятно?
"Не-по децки выполнено" - это как?

[romeo]

2Дуд.
На валидейте Цены Единицы в 37 таблице мы написали модифай других, связанных строк из этой же таблицы. А в юните одном мы написали на временной таблице использование этого валидейта. И было удивительно почему в результате безобидного вроде действия сбрасываются цены в строках, которые вроде как и трогаться не должны.

[Kirvisniemi]

В принципе логично. Кодюнит оперирует временной таблицей, а временная таблица содержит код, который работает с постоянной таблицей.
А вот если использовать в валидейте таблицы исключительно GET, FIND и т.п без рекордов, то все работало бы правильно

[romeo]

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

[zub]

Цитата:

Сообщение от romeo

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

<{POST_SNAPBACK}>

А можно и проверить является ли таблица временной или нет, а от этого и выполнять действия

[romeo]

2Zub.
Никакой функции, позволяющей это сделать, я думаю нет. Да и незачем наверное. Должны знать, с чем имеем дело. И потом если еще такую защиту везде писать, то процент полезного кода уменьшится -)

[zub]

Цитата:

Сообщение от romeo

2Zub.
Никакой функции, позволяющей это сделать, я думаю нет. Да и незачем наверное. Должны знать, с чем имеем дело. И потом если еще такую защиту везде писать, то процент полезного кода уменьшится -)

<{POST_SNAPBACK}>

Функции действительно нет, а способ есть. Для широкого использования он врядли пригодится по причине описанной вами, но иногда выручает

[Greggy_imported]

Не совсем понял.... это значит если на валидейте стоит модификация данных и я вызываю этот валидейт на временной таблице то он будет колбасить данные в реальной таблице что ли?

[romeo]

Цитата:

Сообщение от Greggy

Не совсем понял.... это значит если на валидейте стоит модификация данных и я вызываю этот валидейт на временной таблице то он будет колбасить данные в реальной таблице что ли?

<{POST_SNAPBACK}>

Именно.

[Andywar]

Интересно! Validate делается для поля временной таблицы соответствующей записи. А какая же запись НЕ временной таблицы будет валидэйтиться?

[romeo]

Цитата:

Сообщение от Andywar

Интересно! Validate делается для поля временной таблицы соответствующей записи. А какая же запись НЕ временной таблицы будет валидэйтиться?

В реке когда отрабатывает валидейт прописанные внутри переменные не становятся автоматом тоже временными. Если они объявлены реальными, настоящими, то такими и остаются. Поэтому даже во временной таблице валидейт отрабатывает в соответствии с тем, как он написан. По настоящим, так по настоящим. Само слово "временный" смущать не должно.