To change non-logged database to logged database.

Anything I need to change in 4gl program ?

Probably yes. There are certain things you must do differently or that you
can't do... I should have a list somewhere but for now:

- lock table must be inside a transaction
- there is no "unlock table". Simply close the transaction
- you may get (more) locking errors and the programs should be able to
handle that
- you should prevent long transactions which may force you to split large
operations
- ...
On Aug 9, 2012 8:35 AM, "roger" <roger%star2000.com.tw (AT) gtempaccount (DOT) com>
wrote:

I try compile 4gl program and got error
if program contain " DECLARE CURSOR ... FOR UPDATE".

....In the (missing) context of a discussion about what changes are needed
in an I4GL program when you switch between an unlogged database and a
logged database...

On Thu, Aug 9, 2012 at 3:09 AM, roger <
roger%star2000.com.tw (AT) gtempaccount (DOT) com> wrote:

You need to provide more context. Is it a compile-time or a run-time error?

You have to be in a transaction, I think, to open a cursor FOR UPDATE with
a logged database. However, the system can only detect whether there is a
transaction active at run-time, not at compile-time.

--
Jonathan Leffler <jonathan.leffler (AT) gmail (DOT) com> #include <disclaimer.h>
Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

On Thursday, August 9, 2012 9:34:02 AM UTC+2, roger wrote:
If I remember correctly, the default isolation level is different between a non logged database and a logged database (dirty read v commited read)

Depending how your application currently sets the isolation level, you may need to make some modifications to your application to accomodate this change in behaviour.

The OP needs to add support for atomic transactions to his 4GL apps. That
means surrounding sets of related SQL statements that should be executed as
a complete transaction with BEGIN WORK; ... COMMIT WORK; statements and
trapping errors and issuing a ROLLBACK WORK; statement when they happen. I
would also detect whether the database supports transactions (see the
sqlca.sqlwarn structure immediately after opening the database to see the
logging status of the database) and use transactions or not as appropriate.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/

Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.



On Thu, Aug 9, 2012 at 8:59 AM, scottishpoet <dryburghj (AT) yahoo (DOT) com> wrote:

On 8月9日, 下午7時42分, Jonathan Leffler <jonathan.leff... (AT) gmail (DOT) com> wrote:
Sorry, It is run-time error !