Re: ANSI databases
Posted in 1994
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL, Transactions, Locking & Isolation, Migration, Import/Export & Data Conversion
From article <2l7rveINNeor@emory.mathcs.emory.edu>, by naomi@anasazi.com (Naomi Walker): > > > with non-ansi-compliant code.... > > Because of a problem we are having with row-locking, we are considering > changing our database to MODE ANSI. I am in the process of learning the > ramifications of this move. So far, we have seen that modifying the > create on the database to ANSI helps in one particular circumstance > (without ansi-compliant code (-ansi switch in ESQL/c)). > > What other ramifications (especially subtle) might we experience? I can > create new databases with ansi mode. Can we change a production database > to ansi, or will it have to be unloaded and recreated? > > Thanks, > Naomi > -- > Naomi Walker (aka N7FSA) naomi@anasazi.com > Phoenix, Arizona > > The best things in life aren't things. As far as I can gather it is never necessary to switch to mode ANSI and it is usualy undesirable. You are probably avoiding a problem because the default isolation level for ANSI is REPEATABLE READ which means that your application has a completely stable view of the database but it is hideously inefficient in most cases. If this is the case then I suggest not using ANSI but just changing the isolation level at the critical point. The only thing that ANSI gives you is always being in a transaction and you can program that anyway. Nick Hounsome AT&T Network Systems UK