Devart Forum

raMZES

Замкнутый круг какой-то. Создал тему на форуме с проблемой. Разработчик говорит, что у них все правильно. Приглашают Вас обсудить...

raMZES

Понял. Спасибо. Буду рапортовать о проблеме разработчикам сервера.

raMZES

Здравствуйте. Возникла необходимость получения информации о транзакциях.
Использую:
- IBCConnection.DatabaseInfo.InfoOldestTransaction;
- IBCConnection.DatabaseInfo.InfoOldestActive;
- IBCConnection.DatabaseInfo.InfoOldestSnapshot;
- IBCConnection.DatabaseInfo.InfoNextTransaction;

Однако значение InfoNextTransaction не соответствует действительности. Возможно, имеет место ошибка. Значение совпадает с InfoOldestActive (и InfoOldestSnapshot).

IBDac 4.2.7.

raMZES

Добрый день. Подскажите, будет ли реализована данная функциональность в одном из следующих версий IBDAC? В билде 4.2.8 24-Jul-12 об этом ни слова.

raMZES

Кто-нибудь подскажет как решить?

raMZES

Здравствуйте еще раз. Помогите пожалуйста разобраться с шифрованием при использовании хранимых процедур.

Есть таблица для хранения данных:

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

CREATE TABLE PASSW (
    IDPASS       TINTEGNUM NOT NULL /* TINTEGNUM = INTEGER */,
    READ_PASS    TPASSWORD /* TPASSWORD = VARCHAR(100) */,
    WRITE_PASS   TPASSWORD /* TPASSWORD = VARCHAR(100) */,
    ADV_PASS_ON  TTARIF /* TTARIF = VARCHAR(25) */,
    ADV_PASS     TPASSWORD /* TPASSWORD = VARCHAR(100) */
);

Есть процедура, которая модифицирует\вставляет данные в таблице:

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

create or alter procedure PASSW_IU (
    IDPASS integer,
    READ_PASS TPASSWORD,
    WRITE_PASS TPASSWORD,
    ADV_PASS_ON varchar(25),
    ADV_PASS TPASSWORD)
as
begin
  if (exists(select IDPASS
             from PASSW
             where (IDPASS = :IDPASS))) then
    update PASSW
    set IDPASS = :IDPASS,
        READ_PASS = :READ_PASS,
        WRITE_PASS = :WRITE_PASS,
        ADV_PASS_ON = :ADV_PASS_ON,
        ADV_PASS = :ADV_PASS
    where (IDPASS = :IDPASS);
  else
    insert into PASSW (IDPASS, READ_PASS, WRITE_PASS, ADV_PASS_ON, ADV_PASS)
    values (:IDPASS, :READ_PASS, :WRITE_PASS, :ADV_PASS_ON, :ADV_PASS);
end

Пишу код:

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

...    
    // -------------------------------------------------------------
    // Выбираем процедуру...
    // -------------------------------------------------------------
    DM.WorkHorseSP.Active := false;
    DM.WorkHorseSP.StoredProcName := 'PASSW_IU';
    // ----------------------------------------------------------
    // Подготавливаем
    // ----------------------------------------------------------
    DM.WorkHorseSP.Prepare;
    // -------------------------------------------------------------
    // Присваиваем параметры
    // -------------------------------------------------------------
    DM.WorkHorseSP.Params.ParamByName('IDPASS').AsInteger :=
      DM.QMainIDMAIN.AsInteger;

    DM.WorkHorseSP.Params.ParamByName('WRITE_PASS').Value := Trim
      (edtWritePass.Text); //поле ввода
...
    // -------------------------------------------------------------
    // Шифруем
    // -------------------------------------------------------------
    DM.WorkHorseSP.Encryption.Encryptor := DM.Encryptor;
    DM.WorkHorseSP.Encryption.Fields := 'READ_PASS, WRITE_PASS, ADV_PASS';
    DM.WorkHorseSP.DataTypeMap.AddFieldNameRule('READ_PASS', ftString);
    DM.WorkHorseSP.DataTypeMap.AddFieldNameRule('WRITE_PASS', ftString);
    DM.WorkHorseSP.DataTypeMap.AddFieldNameRule('ADV_PASS', ftString);
    DM.Encryptor.Password := '123';
    // --------------------------------------------------------------
    // Пытаемся выполнить и закомитить
    // --------------------------------------------------------------
    DM.WorkHorseSP.ExecProc;
    if DM.WriteTr.Active then
      DM.WriteTr.Commit;

Данные записываются, но они не зашифрованные.

raMZES

Всё понял. Спасибо.

raMZES

Спасибо за ответы.
Но все же не пойму по поводу п.4. Вы доступно написали, что:

IBDAC сравнивает хэш данных сохраненный в поле на сервере с хэшем который высчитывается на клиенте используя зашифрованные данные. Если на момент чтения данных с сервера IBDAC определяет что данные некорректны и он не может даже расшифровать данные, генерируется исключение EInvalidEncData.

.
Исключение EInvalidEncData генерируется в любом случае, если на момент чтения данных с сервера IBDAC определяет что данные некорректны и он не может даже расшифровать данные?
Независимо, от того, как установлено свойство TCRInvalidHashAction - в ihFail, ihIgnoreError либо ihSkipData?
Не подскажите, как перехватить такое исключение?
Код:

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

procedure TMyForm.OpenConClick(Sender: TObject);
begin
  if not TestConn.Connected then
    try
      TestConn.Connect;
      TestQuery.Open;
    except
      on e: EIBCError do
      begin
        if (e is EInvalidEncData) then
          Application.MessageBox('Невозможно расшифровать данные.', 'Ошибка',
            MB_OK + MB_ICONSTOP + MB_TOPMOST)
        else
          Application.MessageBox('Другая ошибка...', 'Ошибка',
            MB_OK + MB_ICONSTOP + MB_TOPMOST);
      end;
    end;
end;

к сожалению (и естественно) не компилируется.
Спасибо.

raMZES

Добрый вечер. Подскажите пожалуйста ответы на несколько вопросов. Крутятся в голове и все.
Сегодня на работе попробовал новую версию IBDac - 4.2.7 с нужной мне функцией шифрования данных. Прочитал справку с примером шифрования, также нашел топик, где человек просит объяснить, как работает шифрование данных (http://forums.devart.com/viewtopic.php?f=28&t=24452). Там есть код (хотя он и относится к UniDac, я думаю, что в IBDac будет тоже самое):

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

UniQuery.SQL.Text := 'SELECT * FROM EMP';

UniQuery.Encryption.Encryptor := UniEncryptor;
UniQuery.Encryption.Fields := 'ENAME, SAL, FOTO';
UniEncryptor.Password := '11111';

UniQuery.DataTypeMap.AddFieldNameRule ('ENAME', ftString);
UniQuery.DataTypeMap.AddFieldNameRule ('SAL', ftFloat);

UniQuery.Open;

В справке компонент написано:
TCREncryptor supports encryption of string or binary fields only (ftString, ftWideString, ftBytes, ftVarBytes, ftBlob, ftMemo, ftWideMemo).
--
Therefore, to have the possibility to encrypt other data types (such as date, number, etc.), it is necessary to create a field of the binary or BLOB type in the table, and then convert it into the desired type on the client side with the help of data mapping.

Т.е. TCREncryptor поддерживает шифрование для строковых либо двоичных полей. Для остальных используйте Data Type Mapping.
1. Подскажите пожалуйста, обязательно ли использовать Data Type Mapping, как написано в коде:

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

...
ENAME VARCHAR(2000) CHARACTER SET OCTETS COLLATE OCTETS
...

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

...
UniQuery.DataTypeMap.AddFieldNameRule ('ENAME', ftString);
...

для строковых полей?

2. CHARACTER SET OCTETS COLLATE OCTETS указаны просто для того, чтобы сервер не делал никаких преобразований или есть какой-либо другой смысл использования этой кодировки и порядка сортировки?

3. Процедура SetKey. Из справки:
Use SetKey to set a key, using which data is encrypted.
Эта процедура необходима для смены пароля? Можно ли просто при IBQuery.BeforeOpen написать как в примере:

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

UniEncryptor.Password := 'мой пароль';

?

4. TCRInvalidHashAction. Из справки:
ihFail: The EInvalidHash exception is raised and further data reading from the server is interrupted.
ihIgnoreError: In spite of the fact that the data is not valid, the value is set in the field. No exception is raised.
ihSkipData: The value of the field for this record is set to Null. No exception is raised..
То есть, это метод обработки ошибок, когда, как написано, hash data is invalid.
Я попробовал записать данные (с ehTagAndHash) с алгоритмом eaAES128 (свойство InvalidHashAction установил в ihIgnoreError), затем поменял алгоритм на eaBlowfish, перекомпилировал приложение, и при открытии запроса "вылетают" ошибки. Так должно быть?

Заранее благодарен за ответы.

raMZES

Не знал. Спасибо за ссылку.

raMZES

Здравствуйте. ConnectDialog весьма удобная вещь. Подскажите пожалуйста, планируется ли возможность добавить возможность указания роли в нем?

Спасибо.

raMZES

AndreyZ писал(а):Здравствуйте,

Спасибо за информацию. Мы повторили данную проблему и исследуем ее.

Понятно. Спасибо. Если можно, то напишите если исправлено и в какой версии.

raMZES

Здравствуйте. Снова я с вопросом. Подскажите еще пожалуйста выход.

Обычно я в своих проектах использую хранимые процедуры. Например пользователь открывает окно, вводит данные в поля ввода, при нажати на "Сохранить" пишется код:

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

  SP.Active := false;
  SP.StoredProcName := 'MyProc';
  SP.Prepare;
  // ------------------------------------------------------------------------------
  // Присваиваем параметры
  // ------------------------------------------------------------------------------
  SP.Params.ParamByName('MyParam').Value := MyValue;

  try
    WriteTr.StartTransaction;
    //
    SP.ExecProc;
    //
    WriteTr.Commit;
  except
    on e: EIBCError do
    begin
    //мои действия
    end;

Все хорошо, я полностью контролирую запуск и завершение транзакций. Транзакции короткие, все хорошо.

В текущем проекте необходимо редактировать записи прямо в DBGrid. К IBСQuery, как полагается, прикреплено две транзакции. При переходе на следующую запись в гриде, либо при сохранении командой DBNavigator`а транзакция подтверждается. Все хорошо. Но программа будет многопользовательская и запись нужно будет блокировать на время редактирования (на определенное время, например на 2 минуты). Устанавливаю свойство у IBСQuery LockMode в lmLockImmediate, свойство PrepareUpdateSQL в Fasle. IBСQuery начинает подтвеждать транзакции по CommitRetaining. При LockMode lmNone - все нормально. Транзакция подтверждается по Commit. Можно ли сделать так, чтобы IBCQuery подтверждала транзакцию по Commit?

Заранее спасибо.

raMZES

Спасибо за ответ. Т.е. если я правильно понял, то установив свойство IBCQuery.Options.PrepareUpdateSQL в False, запрос будет подготовлен (PREPARE_STATEMENT) один раз и FREE_STATEMENT будет только после IBCTransaction.Commit;

Подскажите пожалуйста, где найти актуальную справку по компонентам? Просто некоторые свойства не описаны.

Еще раз спасибо.

raMZES

Здравствуйте. У меня такой вопрос по работе компонентов.

Есть IBCQuery, две IBCTransaction - одна:

Transaction1
nowait
read_committed
rec_version
read

Другая:

Transaction2
nowait
read_committed
rec_version

К IBCQuery, в качестве Transaction указана первая - Transaction1, читающая, в качестве UpdateTransaction - Transaction2, пишущая. Режим в IBCConnection AutoCommit := true и у IBCQuery тоже.

После изменения записи в Гриде, серверу отсылается комманда COMMIT_RETAINING

У меня вопрос. Почему именно COMMIT_RETAINING? Зачем? Почему не COMMIT_TRANSACTION

Ведь для этого, я так понимаю, у компонента IBCQuery как раз и есть 2 транзакции. В контексте одной данные читаются с сервера, а в контексте другой, UpdateTransaction - записи обновляются и транзакция, в данном случае, сразу подтверждается. Другое дело, когда у компонента только одна транзакция и COMMIT_RETAINING отправляется для подтверждения изменений без закрытия. Тут уж ни как.
Для InterBase с 7.х COMMIT_RETAINING не страшен. Только многие из тех, с кем я общаюсь используют FireBird, а для него COMMIT_RETAINING будет плачевным в плане производительности, т.е. удержания транзакции, накапливании мусора и т.д. Если пользователь будет часто сохранять изменения по COMMIT_RETAINING, могут возникнуть ошибки вроде Too many savepoints

Для интереса я установил триальную версию AnyDAC. Там транзакция после изменения записи сразу подтверждается. Т.е. UpdateTransaction сразу делает COMMIT_TRANSACTION.

FIBPlus от http://devrace.com тоже является двутранзакционным. И тоже завершает обновляемую транзакцию по COMMIT_TRANSACTION.

Можно ли где нибудь настроить нормальное поведение компонентов IBDac?

Спасибо.

P.S. Вырезка из источника IBase.ru
---------------------
Не рекомендуется слишком часто завершать одну и ту же транзакцию по retaining, или производить в каждом таком "интервале" много изменений - это чревато появлением ошибки 287 "too many savepoints" в interbase.log.
Кроме того, транзакция, завершаемая по CommitRetaining, с точки зрения сервера и сборки мусора выглядит как длительно работающая транзакция SNAPSHOT (то есть, CommitRetaining в этом плане не является аналогом Commit). А это значит, что CommitRetaining фактически препятствует сборке мусора, независимо от типа транзакции - Snapshot или ReadCommitted.

Devart Forum

Найдено 30 результатов

Re: Информация IBCDatabase.DatabaseInfo[TransactionInfo]

Re: Информация IBCDatabase.DatabaseInfo[TransactionInfo]

Информация IBCDatabase.DatabaseInfo[TransactionInfo]

Re: Шифрование данных

Re: Шифрование данных

Re: Шифрование данных

Re: Шифрование данных

Re: Шифрование данных

Шифрование данных

IBDac. Роль в ConnectDialog

IbDac. LockMode и транзакции

IBDac и подтверждение транзакций