Re: Change of Logging Status: Implications?

spitz@GANS2X.ana.med.uni-muenchen.de (Richard Spitz) wrote: :Dear Informix Experts, :I just discovered that a large and complex application is running against :a database with no logging. Needless to say, the whole application is :written without transactions, which has been causing numerous consistency :problems in the database. The developer has been catching most of these :problems by giving support to the users over the phone and manually :cleaning up after crashes, but this is now getting out of hand. I had :to convince her that using transactions is mandatory, but I'm worried :about the implications of changing over the database to logging mode. :It is a large application with thousands of lines of code and using lots :of cursors. I know that there are several things you can only do inside :a transaction when the database is defined with logging, but I'm not :sure I know all of them. :So I need info about the implications of changing a database to logging :mode. What problems are to be expected in what parts of a program? I'll :have to assist the developer throughout the migration process, without :knowing too much about the program itself and the database involved. If :I did know, I'd probably quit my job as DBA... These problems have grown :historically without me having had much influence, so please refrain :from comments like "you should have known better". I just have to save :as much as possible. :Database Engine is ONLINE 5.03, the application is written using :ESQL/C 5.01 and 4GL 4.10. All of this is running in client/server :mode with both client and server running on SNI RM400 machines under :SINIX 5.42B. :Answers like "RTFM" are welcome as long as the tell me which FM to R. All the manuals from page 1 to the last page. There *is* no substitute for that. There will never be. There is no way anyone can do serious work without doing that. Read and reread. You can never know too much. Of course the 4GL tutorial has spesific information on transactions. You have to know about isolation levels++. With the normal way of writing applications against a non logging database it will be very very hard to change it. It isn't like writing it from scratch, but it will take a lot of effort. A major part may be open cursors that are closed by commit. Another part may be large updates done in a loop through a cursor and where you have to commit more frequently than after the whole update to avoid a long transaction. You need to know about hold cursors. If any locking is done via a cursor with select for update you may have to change that code. (You should probably replace such locking with optimistic locking using a where clause that compares all fields that are to be updated and possibly others with their orignial value.) There are so many issues you'l have to set up a test site and test every part of the application, not only for testing but also to learn how to do it all. If the programmer haven't done it before (as is apparently the case) she'll have to do a lot of trial and error to get it right. Others will surely give you more and perhaps better input. Good luck. Nils.Myklebust@ccmail.telemax.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company