Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2015.09.10;
Скачать: CL | DM;

Вниз

как можно "залочить" записи?   Найти похожие ветки 

 
Tirael   (2011-04-29 22:38) [0]

использую MYDAC и DBGreedEH

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

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

ЗЫ. возможность просмотра должна остаться, возможность редактирования незалоченных тоже.


 
sniknik ©   (2011-04-29 23:03) [1]

> использую MYDAC и DBGreedEH
а у этого используемого "мудака" субд имеется?

> но не знаю как бы сделать так чтоб компоненты по значнию этого поля запрещали редактировать.
тригер


 
Tirael   (2011-04-30 09:22) [2]

ессно, MySQL

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

ЗЫ сорри, DBGridEh случайно обозвал, к вечеру голова квадратная (


 
Tirael   (2011-04-30 09:44) [3]

ЗЫЫ.

и еще одна проблема с триггерами, он поменять то запретит, но об этом не скажет, просто отменит изменение.

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


 
sniknik ©   (2011-04-30 10:44) [4]

> но об этом не скажет
ексепты


 
ов (дом)   (2011-05-02 12:10) [5]

я б на отрисовку грида предупреждение выдавал


 
Tirael   (2011-05-02 18:17) [6]

угу, но остается вопрос как быть с "привелигированными"?

триггер выполняется в контексте DEFINER`а и CURRENT_USER() или USER() вернут собственно его...

неужель у DBGridEh  нет способа ставить readOnly отдельным записям?


 
Johnmen ©   (2011-05-02 22:55) [7]

Весь вопрос в том, как определяется, кто с привелегией, а кто смерд вонючий....


 
sniknik ©   (2011-05-02 23:02) [8]

> триггер выполняется в контексте DEFINER`а и CURRENT_USER() или USER() вернут собственно его...
точно, точно? а если проверить? т.к. в mssql я вроде бы использовал suser_sname(), ну, или что то  этогого плана в тригере... работало.
мне проверять не охота.

> неужель у DBGridEh  нет способа ставить readOnly отдельным записям?
зачем? правильно ограничения, права, целостность базы поддерживать на уровне субд, и не зависеть от приложения.

на уровне приложения это вообще не проблема... например, у рекордсета есть такой метод как афтерскрол, проверить в нем значение поля и установить readOnly разве проблема? (1 строчка кода...)


 
Ega23 ©   (2011-05-03 11:57) [9]


> неужель у DBGridEh  нет способа ставить readOnly отдельным
> записям?


А это, по-идее, не его забота.



Страницы: 1 вся ветка

Текущий архив: 2015.09.10;
Скачать: CL | DM;

Наверх




Память: 0.49 MB
Время: 0.141 c
6-1276713309
np-600
2010-06-16 22:35
2015.09.10
Делфи и удалёная БД


15-1421098202
Юрий
2015-01-13 00:30
2015.09.10
С днем рождения ! 13 января 2015 вторник


2-1395013278
vegarulez
2014-03-17 03:41
2015.09.10
Indy.TidHTTP. Ошибка HTTP/1.1 302 Found


11-1259759327
MTsv DN
2009-12-02 16:08
2015.09.10
Разыскивается код...


15-1413029873
Kerk
2014-10-11 16:17
2015.09.10
Orpheus,Abbrevia,VirtualTree,SynEdit,LockBox,AsyncPro,PowerPDF