Results 1 to 3 of 3
  1. #1
    Join Date
    Sep 2002

    Unanswered: ODBC-Aufruf fehlgeschlagen.

    Hello all,

    all users get this message when they try to connect and work with the Database which is based on Informix (in german).

    ODBC-Aufruf fehlgeschlagen.
    (3146) [Informix][Informix ODBC Driver][Informix]Not in transaction. (-255) ODBC commit work".

    Its Informix 3.34 32 bit ODBC-Driver and an INFORMIX Client-SDK 2.70.

    The users don't begin a transaction, so I don't understand the fault.

    Does anybody else do?

    Thank you,


  2. #2
    Join Date
    Aug 2002
    I think this error occurs exactly because no begin work statement was set.
    the users want to commit a transaction that is not there.

    finderr -255

    Not in transaction.

    The database server cannot execute this COMMIT WORK or ROLLBACK WORK statement because no BEGIN WORK was executed to start a transaction. Because no transaction was started, you cannot end one. Any database modifications that were made are now permanent; they cannot be rolled back but do not need to be committed. Review the sequence of SQL statements to see where the transaction should have started.

    This error can occur when you open a cursor for update and have not started a transaction yet.

  3. #3
    Join Date
    Dec 2002
    Portland, OR, USA

    More info might help


    I don't know if you are still struggling with this problem or resolved it already, but which OS are you running on, and do you have any other SDK's in the mix?

    We were experiencing odd transaction boundary behavior, using Informix SE 7.25 and Client SDK 2.80 (includes ODBC 3.8) on Red Hat Linux 7.3 (gcc 2.96). The C++ application maintains one or more continuous connections to the DB through a RogueWave SourcePro layer, and it turns out that the database was interpeting the connection as a single transaction! (I am not sure why- this might make sense to somebody, but I still think it's stupid, not that I have an opinion on the subject...) So whenever we hit something that triggered a ROLLBACK, it would take out all the work since the app made the connection.

    And when we tried to use "BEGIN WORK/END WORK" statements, we would get "Already in a transaction" error responses.

    We ended up forcing explicit COMMIT and ROLLBACK statements, trapping for the existing transaction scenario and giving it a COMMIT before explicitly strating our own new one. Not elegant, but at least it seized control back from the black box middle layers. Needless to say, this behavior of the SDK and/or Rogue Wave tool is not well documented or explained anywhere...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts