Re: ANSI vs. Non-ANSI

jimb@csn.net (Jim Benshoof) writes: >We have a third-party vendor that is about to release its Online version >(previously they only offered SE). They are going to make the database a >MODE ANSI database, although I haven't heard much favorable feedback about >ANSI databases. They don't seem to have a good reason for choosing ANSI >so we're hoping to talk them out of this decision. >Can someone help me know all of the ANSI vs. non-ANSI issues so that I can >be informed before we make our case? For starters, ANSI databases use unbuffered logging. Although you may choose to use unbuffered logging with non-ANSI databases, at least you can evaluate the tradeoffs of disk space, performance, and risk of exposure with the different logging modes and make a choice based on your evaluation. You don't have this choice with ANSI databases. Second, applications running against an ANSI database are always in a transaction. There is a default BEGIN WORK executed upon the initiation of every application that talks to an ANSI database, and a default BEGIN WORK executed following every COMMIT or ROLLBACK. Third, the isolation level for applications running against ANSI databases defaults to Repeatable Read. This can wreak havoc with concurrency control and lock management. (With Repeatable Read every row selected within a cursor has a shared lock placed on it from the time the first such row is fetched until the cursor is closed.) ___ ___ Senior Consultant / ) __ . __/ /_ ) _ _ __ Informix Software Inc. (303) 850-0210 _/__/ (_(_ (/ / (_(_ _/__) (-' ~/ '(_- 5299 DTC Blvd #740 Englewood CO 80111