iBase.ru Forum

такой вопрос, у меня есть таблица и yaffil можно ли в разрезе одной таблицы реализовать ограничение на изменения определенных полей, оставив при изменении, старые значения а если изменяют поля этой же таблицы но разрешоные то изменения вносятся, есть у меня две идеи как это сделать 1) на уровне клиентской части в onBeforeUpdate
2) триггерами
Но в клиентской части нужно будет ввести распознование ролей...что меня не особо радует так что я склоняюсь к первому варианту, кто сталкивался с такими проблемами может мне текст готового тригера выложить )))...и п/с что то я не могу найти обращение к роле есть sql операто role но когда делаеш сравнение типа if (Role = 'role1') он ругается на это в книжке по ибэйзу ничего интересного нет на эту тему вот так вот сумбурно. Подитожу
1) если не трудно расскажите кто как выходил из подобной ситуации
2) если не трудно можно текст готового тригера на ограничение на запись в полях
3) и если не трудно правильно построеное синтаксическое обращение к роли в ibase (yaffil
Буду очень благодарен

типа if (Role = 'role1') он ругается на это в книжке по ибэйзу

current_role. В какой книжке?

реализовать ограничение на изменения определенных полей, оставив при изменении, старые значения а если изменяют поля этой же таблицы но разрешоные то изменения вносятся,

очень мутно. поподробней бы.

1) спасибо
2) мир interBase (хотя сама книжка сокровище )
3) попробую на гипотетическом примере

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

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

А если посчитать эти поля разными сущностями, связанными один к одному, соответственно 2 таблицы связанные внешним ключем. Это как один из подходов к проблеме.

shamash писал(а):1) спасибо
есть таблицы в которой два поля, у юзера (user1) есть право редактировать удалять одно поле(field1) и нет права редактировать, удалять второе(field2) поле, повторюсь, что поля находятся в одной таблице. соответственно у второго пользователя есть право редактировать field2 и нет возможности не удалять не изменять field1
вот примерно так

Ну. И чего ты теперь хочешь от триггера, если и так у каждого права только на свои поля?

Ivan_Pisarevsky писал(а):А если посчитать эти поля разными сущностями, связанными один к одному, соответственно 2 таблицы связанные внешним ключем. Это как один из подходов к проблеме.

мм поконкретнее...мутно

Merlin писал(а): Ну. И чего ты теперь хочешь от триггера, если и так у каждого права только на свои поля?

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

Мегамозги вообще явление в природе редкое, но ты даже не Язык. Набор слов какой-то гонишь бессвязный. RTFM Language Reference на предмет Grant и заодно ещё Try ... Except в хелпе по Дельфям, если ты на них пишешь.

я практик, поэтому конкретные замечания и вопросы если не трудно.. можно вашим языком ..если замечания к моему языку будут обоснованы пересмотрю метод общения... c грантами там вообще не связано все должно быть реализовано на программном уровне.. exeption сейчас думаю потому как нужно на каждое поле все это сделать...плюс откатывать изменения после добавления, обновления поля, слишком много привязок идет...меня интерисует вопрос встречался кто либо с данным вопросом и как практически решил, что соответственно мне и нужно, стандартные средства кто решает на на уровне клиентского приложения, кто на уровне тригеров. И как.

shamash писал(а):

Ivan_Pisarevsky писал(а):А если посчитать эти поля разными сущностями, связанными один к одному, соответственно 2 таблицы связанные внешним ключем. Это как один из подходов к проблеме.

мм поконкретнее...мутно

Ты задал очень общий вопрос, а хочешь конкретный ответ...
Термины: универсальное отношение, формы Бойса кода, сущность-связь, нормализация и тп... тебе о чем-нибудь говорят? Если нет, то стоит взять книжку по проектированию баз данных и почитать. Отпадет масса вопросов, причем сами-собой.

К тому же я не вижу проблемы в попытке обновить триггером запрещенное поле, если стоит запрет, он отвалится эксепшеном, лови этот эксепшн конструкцией try ... except ... end. Вобщем к словам Мерлина добавить пока нечего

понятно .. спасибо и на том. читали все читали... try exception так и сделаем на готовом примере понятен и общий смысл и направление мысли...а словами каждый может будем исправлятся