Re: Change of Logging Status: Implications?

>Date: Thu, 1 Aug 1996 13:28:58 -0700 (PDT) >From: Will Hartung - Master Rallyeist <villy@collinscomp.com> >X-Informix-List-Id: <list.10896> > >[ From no logging to logging problems ] >[...] >Where you're going to have your biggest headaches, I imagine, is going >to be in concurrency. >[...] It depends on how you've written your code, but if you've got any cursors declared for a SELECT ... FOR UPDATE, then each of those must be inside a transaction when the cursor is opened. This is, in my experience, one of the more serious problems with converting from unlogged to logged databases. I always develop against a logged database, but I use dummy functions in place of BEGIN WORK, COMMIT WORK and ROLLBACK WORK which find out (preferably at start up) whether the database has transactions or not, and only do the relevant operation if the database does have transactions. It is much easier to convert from logging to unlogged than the other way round, though if the code is designed to rely on rollback undoing things, the switch is not painless either way. Also be aware that you can only lock tables inside a transaction, and you can't unlock them except via COMMIT/ROLLBACK WORK. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>