Re: <No Subject Supplied>
Posted in 1993
>From: uunet!cbnewsh.cb.att.com!ijk (ihor.j.kinal) >Subject: Re: <No Subject Supplied> >Date: Thu, 8 Jul 1993 18:22:29 GMT >X-Informix-List-Id: <news.3774> >In article <1993Jul8.143903.18109@informix.com>, davek@newjersey.informix.com (Dave Kosenko) writes: >> naomi@qip.anasazi.com writes: >> |> > Alternatively, if you don't actually need Committed Read isolation, just >> |> > SET ISOLATION TO DIRTY READ, and it will work fine. >> |> The problem I have with setting ISOLATION is that it affects the entire >> |> database, and sometimes I only want a particular table. >> You could, of course, only execute the isolation change immediately before >> querying that table, then set it back as soon as you are done. > ^^^^^^^^^^^ >That's correct, as far as it goes. We've encountered, a problem, >however, in that we sometimes want to write modular library routines. >Thus, we DON'T KNOW what the original level was to set it back >to. And there's no way of querying the engine that we know of. >[I guess this is really an enhancement request]. Fair enough. You can, and probably should, write a set of interface routines to the SET ISOLATION statement, such that you can use: LET old_level = get_isolation() CALL set_isolation("new level") ... do work at new level CALL set_isolation(old_level) You might want to have set_isolation() return the old level; in that case, you should probably allow set_isolation("same level") to simply find the current isolation level. You can use the same technique for any of the I4GL state setting statements. I agree you should be able to find out the current value of everything -- I included that as a requirement in the list of modifications to I4GL which I sent out in February. But you can impose the discipline of using functions to provide the current state. One of the best features of I4Gl is that where the language has forgotten something, you can write code to provide the missing functionality. Of course it's a nuisance, but at least you can get around the problem in a reasonably orthodox (and totally supportable) manner. Yours, Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>