-
использую MYDAC и DBGreedEH
задача состоит в том, что когда заказ отправлен в производство, нужно навсегда запретить редактирование тех записей, которые относятся к заказу.
придумал добавить ко всем таблицам булево поле, и при "лочке" устанавливать это поле для всего дерева, но не знаю как бы сделать так чтоб компоненты по значнию этого поля запрещали редактировать.
ЗЫ. возможность просмотра должна остаться, возможность редактирования незалоченных тоже.
-
> использую MYDAC и DBGreedEH а у этого используемого "мудака" субд имеется?
> но не знаю как бы сделать так чтоб компоненты по значнию этого поля запрещали редактировать. тригер
-
ессно, MySQL
я хотел делать делать это на клиенте, потому как осбо привилегированным аккаунтам все же нужно дать возможность редактирования, (например название потребуется чуть подправить и т.п.) триггеры вроде как переменных не принимают, а снимать лочку совсем нельзя - в это время ктото другой может "наредактировать"
ЗЫ сорри, DBGridEh случайно обозвал, к вечеру голова квадратная (
-
ЗЫЫ.
и еще одна проблема с триггерами, он поменять то запретит, но об этом не скажет, просто отменит изменение.
т.е. ктото неособо вникнувший, может вместо правильного пути (создания версии или модификации детали) для нового заказа просто поредактировать старую и включить ее в новый зказ. причем о том что она не отредактировалась он может даже не догадаться... потому как в гриде то все редактируется на ура, и только хитрый триггер знает...
-
> но об этом не скажет ексепты
-
я б на отрисовку грида предупреждение выдавал
-
угу, но остается вопрос как быть с "привелигированными"?
триггер выполняется в контексте DEFINER`а и CURRENT_USER() или USER() вернут собственно его...
неужель у DBGridEh нет способа ставить readOnly отдельным записям?
-
Весь вопрос в том, как определяется, кто с привелегией, а кто смерд вонючий....
-
> триггер выполняется в контексте DEFINER`а и CURRENT_USER() или USER() вернут собственно его... точно, точно? а если проверить? т.к. в mssql я вроде бы использовал suser_sname(), ну, или что то этогого плана в тригере... работало. мне проверять не охота.
> неужель у DBGridEh нет способа ставить readOnly отдельным записям? зачем? правильно ограничения, права, целостность базы поддерживать на уровне субд, и не зависеть от приложения.
на уровне приложения это вообще не проблема... например, у рекордсета есть такой метод как афтерскрол, проверить в нем значение поля и установить readOnly разве проблема? (1 строчка кода...)
-
> неужель у DBGridEh нет способа ставить readOnly отдельным > записям?
А это, по-идее, не его забота.
|