Транзакции Interbase

[lesav]

Прикольно, но лучше собирать драйвер из консоли, а не из креатора....

Все в норме

Перелопатил IbppDriver, теперь собирается в Qt4 и Qt5, в консоле и креаторе

http://Lesav.ru/prog.org.ru/AxQtFbIbppSqlDriver.7z

В архиве собранные и проверенные драйверы для:

• qt486_win32.x86_mingw482
• qt486_win32.x86_msvc2010
• qt530_win32.x86_mingw482
• qt530_win32.x86_msvc2010

[break]

Ibpp тут не при чем. При сборке в креаторе не всегда вызывается moc на нужные файлы - корректная сборка в случае с плагином будет происходить через раз по случайному принципу. Ссылку почему дал.

[lesav]

Чтобы вызвался moc необходимо чтобы в файле был Q_OBJECT

В вашем main.cpp  Q_OBJECT небыло

[break]

Нет - опять не верно. Q_OBJECT  есть в предке, да и в наследнике он был - и MOC все равно не вызывался - я дал ссылку на ошибку QTCreator-а по причине которой вызывался qmake -r вместо qmake и именно из-за этого не всегда происходила правильная сборка. Вам следует изучить предоставленный материал!

https://github.com/qreal/qreal/issues/209

И для справки - MOC  натравливается только на H файлы. Первый рабочий вариант, который я показал - до выяснения проблемы со сборкой - я уже перенес описание класса в H файл!

В вашем случае МОК наравливается на CPP  хаком через "#include MAIN.MOC"

[lesav]

В вашем случае МОК наравливается на CPP  хаком через "#include MAIN.MOC"

MAIN.MOC это выхлоп от moc.exe.   Ну да ладно. 


У вас проблем с драйвером нет ? В частности корректно отображаются поля TIMESTAMP ?

Я заметил, что моя JS-обертка драйвера возвращает в QScriptEngin данные типа "02-06-2014 00:00:00" вместо необходимого "02-06-2014 06:40:35"

У вас таких проблем нет ?

[break]

Да похоже тоже ошибка присутствует... 

Вывод:

QDateTime("2014-06-02 00:00:00.000 MSK Qt::LocalTime")

в БД:

02.06.2014, 17:15:36.117

[break]

Странно... Драйвер возвращает количество миллисекунд на порядок большее чем надо (число мсек * 10 )

QDateTime fromIBPPTimeStamp(IBPP::Timestamp&) 154 | 17 15 36 1170

Легко поправляется в исходнике драйвера - интересно раньше эта проблема тоже была?

Код:

static QDateTime fromIBPPTimeStamp(IBPP::Timestamp &dt)
{
    int y,m,d,h,min,s,ms;
    dt.GetDate(y,m,d);
    dt.GetTime(h,min,s,ms);
    return QDateTime(QDate(y,m,d), QTime(h,min,s,ms/10));
}

[break]

Кстати удобнее использовать не ilReadCommited  константу, а константу ilReadDirty в параметрах настройки уровня изоляции транзакции. Это ReadCommited с опцией RecordVersion

#define TRANS_SELECT "TAM=amRead, TIL=ilReadDirty, TLR=lrNoWait, TFF=0"

READ COMMITTED (константа read_committed) - уровень изоляции ReadCommitted. Т.е. в данной транзакции все изменения, которые были подтверждены другими транзакциями, будут видны немедленно. Имеет две опции:

NO RECORD_VERSION (константа no_rec_version) - если при чтении пакета версий записи (о версионности "в двух словах см. www.ibase.ru/devinfo/mga.htm) обнаруживается non-committed версия, то выдается или deadlock (в режиме no wait) или транзакция зависает на блокировке (в режиме wait). По умолчанию для режима READ COMMITTED в IB API.

RECORD_VERSION (константа REC_VERSION) - игнорирует non-committed версии, читая последнюю committed-версию (см. выше no_rec_version). Именно этот режим является умолчательным в BDE (начиная с версии BDE 4.01. см. документ), и рекомендуется для нормальной работы в режиме read committed.

примечание: как выяснилось (в 2010) году, многие разработчики драйверов (Firebird ODBC, Firebird .Net driver (DNET-337) и т.д.) почему-то считают, что для read_committed нормальным является режим no record_version, вызывающий блокировки по чтению non-committed данных. Это является неестественным, т.к. InterBase и Firebird ни при каком уровне изолированности не допускают чтения non-committed данных. Более того, версионность в первую очередь предназначена для того, чтобы обеспечивать бесконфликтное чтение подтвержденных (committed) данных.
В любом случае, если вы видите deadlock при чтении, значит ваш драйвер или компоненты используют именно no record_version для read committed. Если возможно (позволяет драйвер или компоненты), попытайтесь это исправить настройками параметров транзакции.
В большинстве компонентов прямого доступа (IBX, FIBPlus и т.д.) умолчательным для режима ReadCommitted как раз является record_version, не выдающий блокировок при чтении non-committed данных.

http://www.ibase.ru/devinfo/ibtrans.htm

[lesav]

Подправил драйвер (что исправлено)

http://Lesav.ru/prog.org.ru/AxQtFbIbppSqlDriver.7z
В архиве собранные и проверенные драйверы для:

• qt485_win32.x86_mingw440
• qt485_win32.x86_mingw481
• qt485_win32.x86_msvc2010
• qt486_win32.x86_mingw482
• qt486_win32.x86_msvc2010
• qt520_win32.x86_mingw480
• qt520_win32.x86_msvc2010
• qt521_win32.x86_mingw480
• qt521_win32.x86_msvc2010
• qt530_win32.x86_mingw482
• qt530_win32.x86_msvc2010

[eJinn]

У вас проблем с драйвером нет ? В частности корректно отображаются поля TIMESTAMP ?

Это известная ошибка драйвера
Необходимо изменить код драйвера src/sql/drivers/ibase/qsql_ibase.cpp
 тут:

Код:

static QDateTime fromTimeStamp(char *buffer)
{
    static const QDate bd(1858, 11, 17);
    // !!!! QTime t;
    QTime t(0,0,0,0);
    QDate d;

и, аналогично, тут:

Код:

static QTime fromTime(char *buffer)

и пересобрать драйвер.

PS К моему великому сожалению у меня потребовали переделать проект под MySQL. Вот так.

[break]

Столкнулся с такой ситуацией - не получается "правильно" использовать метод prepare класса QSqlQuery

То есть нельзя полсе exec снова сделать множественные bindValue и снова запустить exec - возвращается ошибка "No statement have been prepared" - приходится делать prepare запроса с параметрами каждый раз, что сводит смысл использования prepare на нет.....


Так же не работает привязка через bindValue если плейсхолдеры были указаны в запросе и переданы QSqlQuery в конструкторе... Но это мелочь конечно.

Кто нибудь сталкивался?

[break]

Вообще-то работает если до создания QSqlQuery стартовать транзакцию явно через db.transaction();
тогда до следующего commit-а все работает

Если не стартовать - то не работает, со стандартным драйвером работало, что и запутало при переводе очередного проекта на этот драйвер. Кто нибудь знает какие параметры транзакции использует стандартный драйвер?

[break]

Интересные наблюдения в продолжение двух предыдущих моих сообщений. В зависимости от того явно или не явно управлять стартом транзакций, запросы на чтение и запросы на обновление данных работают по разному. Как будто QSqlQuery делает внутри себя commit в случае запроса на изменение данных.

Например такой код работает всегда:

QSqlQuery q;
q.prepare( "select * from TEMP_TBL_1 where PROCESS_CODE = :PROCESS_CODE" );
q.bindValue( ":PROCESS_CODE", 123 );
q.exec();
q.bindValue( ":PROCESS_CODE", 123 );
q.exec();


Выполнятся оба запроса без ошибок. А такой не работает, если предварительно не стартовать транзакцию вручную через db.transaction();

QSqlQuery q;
q.prepare( "INSERT INTO TEMP_TBL_1(WORK_ROW_ID, PROCESS_CODE) VALUES(:WORK_ROW_ID, :PROCESS_CODE)" );
q.bindValue( ":WORK_ROW_ID", i );
q.bindValue( ":PROCESS_CODE", 123 );
q.exec();
q.bindValue( ":WORK_ROW_ID", i );
q.bindValue( ":PROCESS_CODE", 123 );
q.exec();


Выполнится только первый запрос, а на второй выведется ошибка

void QFBResultPrivate::setError(const string&, IBPP::Exception&, QSqlError::ErrorType) 403 | *** IBPP::LogicException ***
Context: Statement::Execute
Message: No statement has been prepared


А если сделать так - то все работает гладко


dbManager()->startTransaction();
QSqlQuery q;
q.prepare( "INSERT INTO TEMP_TBL_1(WORK_ROW_ID, PROCESS_CODE) VALUES(:WORK_ROW_ID, :PROCESS_CODE)" );
q.bindValue( ":WORK_ROW_ID", i );
q.bindValue( ":PROCESS_CODE", 123 );
q.exec();
q.bindValue( ":WORK_ROW_ID", i );
q.bindValue( ":PROCESS_CODE", 123 );
q.exec();
dbManager()->commit_DB();


Это все в продвинутом фаерберд драйвере, но предположу, что не от драйвера qt это зависит (пока нет возможности проверить). Может этому есть логичное объяснение - и все так и должно быть?

[break]

Проверил со стандартным драйвером IBase - там такого поведения нет - всем кто будет использовать продвинутый рекомендую об этом помнить )

[break]

Подтверждение в исходниках QFBDriverPlugin - автор так и планировал

bool QFBResult::exec()

Код:

    if (!rp->isSelect())
        rp->commit();

bool QFBResultPrivate::commit()

Код:

    if (!localTransaction)
        return true;