iBase.ru Forum

slv2 писал(а): 1. Есть ли способ лучше?

stix-s писал(а):

slv2 писал(а): 1. Есть ли способ лучше?

Раздать права на модификацию полей по пользователям (по ролям)

stix-s писал(а): Использовать компоненты FIB+

Merlin писал(а):

stix-s писал(а): Раздать права на модификацию полей по пользователям (по ролям)

И што? Он это и сделал, после чего стал получать отлуп на препаре запроса.

Merlin писал(а):

stix-s писал(а): Использовать компоненты FIB+

И што буит?

stix-s писал(а):

Merlin писал(а):

stix-s писал(а): Раздать права на модификацию полей по пользователям (по ролям)

И што? Он это и сделал, после чего стал получать отлуп на препаре запроса.

В свое время пробовал с компонентом TpFIBDataSet - не ругался, просто втихую запрос модифицировал и все.

Merlin писал(а):

stix-s писал(а): Использовать компоненты FIB+

И што буит?

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

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

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

Насчёт блобов - выдели алгоритмически их редактирование в отдельную ветку, проще будет.

Или фиксипуй факт редактирования скажем в TAG-е поля на каком-нить его событии и потом поо нему ориентируйся при сохранении.

Использовать компоненты FIB+

slv2 писал(а): Как бы ты решил данную проблему?

slv2 писал(а):

Насчёт блобов - выдели алгоритмически их редактирование в отдельную ветку, проще будет.

Ты имеешь ввиду использовать не DB-компонент, а простой контрол и при посте загружать данные из него в поле?

slv2 писал(а):

Или фиксипуй факт редактирования скажем в TAG-е поля на каком-нить его событии и потом поо нему ориентируйся при сохранении.

В принципе подходит. Но если пользователь начал редактирование, а потом передумал и вернул поле в начальное состояние, то метка все равно ведь останется.

При редактировании поднимается отдельная форма, запись рефрешится в её не db-aware контролы, сохранение результатов у меня крайне редко идёт только в одну таблицу и даже в одной транзакции. То есть выполняется несколько автономных TIBSQL или TIBQuery.ExecSQL, которые частенько собираются динамически по обстоятельствам. или вызываются TIBStoredProc.

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

TBlobField(Field).Modified

В свое время пробовал с компонентом TpFIBDataSet - не ругался, просто втихую запрос модифицировал и все.

{
DataSet - датасет с которым работаем
FieldNames - список полей, разделенных двоеточием которые нужно проверить на предмет изменения (не всегда ведь нужно проверять все поля, например при джоине)
Quote - заключать названия параметров в кавычки?
}
function SQLGetUpdatedFields(DataSet: TDataSet; const FieldNames: string;
  Quote: boolean): string;
var
  i: Integer;
  TmpStr: string;
  Fields: TStrings;

  function GetUpdatedField(Field: TField; out SQL: string): boolean;
  begin
    if Field.IsBlob then
      Result := TBlobField(Field).Modified
    else
      Result := Field.NewValue <> Field.OldValue;

    if Result then
    begin
      if Quote then
        SQL := Field.Origin + '=:' + '"' + Field.FieldName + '"'
      else
        SQL := Field.Origin + '=:' + Field.FieldName;
    end;
  end;

begin
  Result := '';
  Fields := TStringList.Create;
  try
    Fields.Text := StringReplace(FieldNames, ':', #13, [rfReplaceAll]);
    for i := 0 to Fields.Count - 1 do
    begin
      if GetUpdatedField(DataSet.FieldByName(Fields[i]), TmpStr) then
      begin
        if Result <> '' then
          Result := Result + ', ' + #13;
        Result := Result + TmpStr;
      end;
    end;
  finally
    Fields.Free;
  end;

end;

procedure TfrmForm.ibqQueryBeforePost(DataSet: TDataSet);
var
  UpdatedFields: string;
begin
  UpdatedFields := SQLGetUpdatedFields(ibqQuery,
    'field1:field2:field3:notes', true); //Получаем список измененных полей
  if UpdatedFields = '' then
  begin
    ibqQuery.Cancel; //Если пуст отменяем редактирование
    Abort;  //И аборт (в смысле прекращаем операцию)
  end;
    
  with ibusUpdateSQL.ModifySQL do
  begin
    Clear;
    Add('UPDATE "table" SET ');
    Text := Text + UpdatedFields;
    Add(' WHERE "id" = :"OLD_id"');
  end;
end;

Круто

Зачем вы так операцию на глазах делаете? Список измененных полей получают вот так:

Код: Выделить всё

for I := 0 to Fields.Count - 1 do 
  if Fields[I].NewValue <> Fields[I].OldValue then 
    ...

Код: Выделить всё

  function SQLGetUpdatedField(Field: TField; out SQL: string): boolean; 
  begin 
    Result := Field.NewValue <> Field.OldValue; 
    if Result then 
      SQL := Field.Origin + '=:' + Field.FieldName; 
  end;

Плюс: если поле изменили, а потом вернули старое значение, датасет будет считаться немодифицированным, а у вас - модифицированным.

Но если пользователь начал редактирование, а потом передумал и вернул поле в начальное состояние, то метка все равно ведь останется.

Код: Выделить всё

  if UpdatedFields = '' then 
  begin 
    ibqQuery.Cancel; //Если пуст отменяем редактирование 
    Abort;  //И аборт (в смысле прекращаем операцию) 
  end;

slv2 писал(а):А так мы получаем список полей которые редактировались вообще.
И это правильно ибо нечего пользователем редактировать поля которые редактировать им не разрешено.

Чушь, по-моему. Сначала открываем всё, а потом начинаем собирать статистику, куда пользователь полез, куда хотел полезть, куда по ошибке залез...

Может, поля недоступные для конкретного пользователя, делать ReadOnly, и не проверять "куда он хотел, но не полез"?

slv2 писал(а):А если в следующих версиях сервера чего-нибудь изменится в плане хранения прав доступа?

slv2 писал(а): Поверьте, я над этим вопросом думал не один час...
А если в следующих версиях сервера чего-нибудь изменится в плане хранения прав доступа?

WildSery писал(а):Тогда надо будет поменять только этот запрос.

Karp писал(а):2) завести табличку с правами для юзеров;
3) если есть права на редактирование поля, то соответствующий контрол доступен для ввода/изменения, если нет - то только просмотр значения.

права давать в виде набора битов, а на клиенте их проверять и делать доступными или недоступными нужные кнопки, контролы "и что у них есть ещё там" (с)

slv2 писал(а):Плохо это с точки зрения безопасности. Всегда найдется продвинутый пользователь который вместо ввода данных наберет что-то типа UPDATE ... SET ...

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