How to know the current isolation level in ESQL/C?
The OP asked how an ESQL/C program can find out its current transaction isolation level. Art Kagel explained the default depends on the database logging mode (dirty read for unlogged, committed read for logged, repeatable read for ANSI), detectable via sqlca.sqlwarn1/sqlwarn2 right after DATABASE/CONNECT, with USELASTCOMMITTED only visible in sysmaster:sysconfig; Jonathan Leffler said there's no API call, so the app must track changes itself. Fernando Nunes offered a query joining sysmaster:sysopendb and flags_text on DBINFO('sessionid') to report it, though caveats were raised about multiple/remote transactions having differing levels. No confirmation from the OP is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
please see the subject.
Lu: When a session first connects to a database the isolation level is determined by the logging mode of the database: Unlogged: Dirty Read ANSI Mode: Repeatable Read non-ANSI Logged: Committed Read You can detect the logging mode of the database immediately after the DATABASE or CONNECT statement that opens the database by examining the sqlca structure. The sqlca.sqlwarn1 field will be set to 'W' if the database has logging (so not unlogged). In addition, if the database is an ANSI mode logged database the sqlca.sqlwarn2 field will also be set to 'W' along with sqlca.sqlwarn1. If neither is set then the database is unlogged. There is, unfortunately, no direct way to detect if the LAST COMMITTED option has been added as a default sub-mode by the operation of the USELASTCOMMITTED parameter in the ONCONFIG file except to check the sysmaster:sysconfig table and look at the cf_effective field value for this parameter to see if it is active. If the isolation level is anything but the default it would have had to be set inside the application, so the application should know what it set it to. I guess an app that accepts user input SQL might have a problem, but you could describe the user entered SQL and the sqlda structure will tell you the statement type so even then you could keep track of the current isolation level in a global variable. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Dec 30, 2015 at 10:28 AM, CHUAN LU <luchuan@cn.ibm.com> wrote: > please see the subject. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --047d7bfe9fe8f86053052820172b
On Wed, Dec 30, 2015 at 7:28 AM, CHUAN LU <luchuan@cn.ibm.com> wrote:
> please see the subject.
>
Please don't make us see the subject repeat the question in the body of
the email.
> How to know the current isolation level in ESQL/C?
AFAIK, there isn't a way to discover the isolation level in ESQL/C; you
have to know it by tracking it yourself. You need to use a function (or
something similar) that tracks the current isolation level, and use that
whenever you change the isolation level.
Note that isolation level is really something the server handles and
tracks; it really doesn't affect the ESQL/C at all. If you're really
desparate, you could probably arrange to run 'onstat' and discover the
information from one of its outputs, but that's downright tricky to do if
the server is on a different machine from the ESQL/C code.
--
Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
--001a113f8264a401f6052820bb7e
This should work:
SELECT
t.txt
FROM
sysmaster:sysopendb d, sysmaster:flags_text t
WHERE
d.odb_sessionid = DBINFO('sessionid') AND
d.odb_isolation = t.flags AND
d.odb_iscurrent ='Y' AND
t.tabname = 'sysopendb'
I have the feeling that there was some catch, but I can't remember....
One thing I do remember is that some old versions didn't provide a complete
list (the flags_text table was not correctly populated).
You can encapsulate this in a SPL...
Probably the catch is that I believe each open transaction can have it's
own isolation level and in ESQL/C you may handle multiple concurrent
transactions.... Not sure what the result will be with this method. But I'd
have to check if multiple transactions require different sessions.... I
don't think so, but Jonathan knows this better than anyone. I'd have to
check.
It's not the first time this question is asked and I alwasy confuse myself
into thinking I've written an article about this. Each time I end up
finding that what I did was about finding out if we were in the middle of a
transaction. I've done that in C (server side funtion) but I couldn't find
a function that would tell me this.
You could add an RFE for this... as an option for DBINFO() for example....
(actually I thought there was one already but I couldn't find it)
Regards.
On Wed, Dec 30, 2015 at 5:19 PM, Jonathan Leffler <
jonathan.leffler@gmail.com> wrote:
> On Wed, Dec 30, 2015 at 7:28 AM, CHUAN LU <luchuan@cn.ibm.com> wrote:
>
> > please see the subject.
> >
>
> Please don't make us see the subject repeat the question in the body of
> the email.
>
> > How to know the current isolation level in ESQL/C?
>
> AFAIK, there isn't a way to discover the isolation level in ESQL/C; you
> have to know it by tracking it yourself. You need to use a function (or
> something similar) that tracks the current isolation level, and use that
> whenever you change the isolation level.
>
> Note that isolation level is really something the server handles and
> tracks; it really doesn't affect the ESQL/C at all. If you're really
> desparate, you could probably arrange to run 'onstat' and discover the
> information from one of its outputs, but that's downright tricky to do if
> the server is on a different machine from the ESQL/C code.
>
> --
> Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
> Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
> "Blessed are we who can laugh at ourselves, for we shall never cease to be
> amused."
>
> --001a113f8264a401f6052820bb7e
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--089e01229aaa1881210528212c7f
Fernando:
It's even funkier than you think:
1. There is a default isolation level for the connection to the database.
2. A change in isolation level MAY or MAY NOT affect existing cursors
and transactions.
3. Multiple transactions could be started under different isolation
levels.
4. The effective isolation level for a distributed or remote transaction
may have nothing to do with the isolation level for the session that owns
the transaction since its isolation may be based on the connected database
while the transaction's effective isolaton level for the remote or
distributed transaction may depend on those of the remote database(s) being
accessed.
It is a hairball.
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Wed, Dec 30, 2015 at 12:50 PM, Fernando Nunes <domusonline@gmail.com>
wrote:
> This should work:
>
> SELECT
>
> t.txt
> FROM
>
> sysmaster:sysopendb d, sysmaster:flags_text t
> WHERE
>
> d.odb_sessionid = DBINFO('sessionid') AND
>
> d.odb_isolation = t.flags AND
>
> d.odb_iscurrent ='Y' AND
>
> t.tabname = 'sysopendb'
>
> I have the feeling that there was some catch, but I can't remember....
> One thing I do remember is that some old versions didn't provide a complete
> list (the flags_text table was not correctly populated).
> You can encapsulate this in a SPL...
>
> Probably the catch is that I believe each open transaction can have it's
> own isolation level and in ESQL/C you may handle multiple concurrent
> transactions.... Not sure what the result will be with this method. But I'd
> have to check if multiple transactions require different sessions.... I
> don't think so, but Jonathan knows this better than anyone. I'd have to
> check.
>
> It's not the first time this question is asked and I alwasy confuse myself
> into thinking I've written an article about this. Each time I end up
> finding that what I did was about finding out if we were in the middle of a
> transaction. I've done that in C (server side funtion) but I couldn't find
> a function that would tell me this.
>
> You could add an RFE for this... as an option for DBINFO() for example....
> (actually I thought there was one already but I couldn't find it)
> Regards.
>
> On Wed, Dec 30, 2015 at 5:19 PM, Jonathan Leffler <
> jonathan.leffler@gmail.com> wrote:
>
> > On Wed, Dec 30, 2015 at 7:28 AM, CHUAN LU <luchuan@cn.ibm.com> wrote:
> >
> > > please see the subject.
> > >
> >
> > Please don't make us see the subject repeat the question in the body of
> > the email.
> >
> > > How to know the current isolation level in ESQL/C?
> >
> > AFAIK, there isn't a way to discover the isolation level in ESQL/C; you
> > have to know it by tracking it yourself. You need to use a function (or
> > something similar) that tracks the current isolation level, and use that
> > whenever you change the isolation level.
> >
> > Note that isolation level is really something the server handles and
> > tracks; it really doesn't affect the ESQL/C at all. If you're really
> > desparate, you could probably arrange to run 'onstat' and discover the
> > information from one of its outputs, but that's downright tricky to do if
> > the server is on a different machine from the ESQL/C code.
> >
> > --
> > Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
> > Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
> > "Blessed are we who can laugh at ourselves, for we shall never cease to
> be
> > amused."
> >
> > --001a113f8264a401f6052820bb7e
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --089e01229aaa1881210528212c7f
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a1141f3e25b75620528219fa2
Yes... But the question was about the "current" isolation level... I assume
the OP needs this because within a function it may need to change it, but
then restore the original.
But he didn't explain it...
On Wed, Dec 30, 2015 at 6:22 PM, Art Kagel <art.kagel@gmail.com> wrote:
> Fernando:
>
> It's even funkier than you think:
>
> 1. There is a default isolation level for the connection to the database.
>
> 2. A change in isolation level MAY or MAY NOT affect existing cursors
>
> and transactions.
>
> 3. Multiple transactions could be started under different isolation
>
> levels.
>
> 4. The effective isolation level for a distributed or remote transaction
>
> may have nothing to do with the isolation level for the session that owns
>
> the transaction since its isolation may be based on the connected database
>
> while the transaction's effective isolaton level for the remote or
>
> distributed transaction may depend on those of the remote database(s) being
>
> accessed.
>
> It is a hairball.
>
> Art
>
> Art S. Kagel, President and Principal Consultant
> ASK Database Management
> www.askdbmgt.com
>
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on the IIUG, nor any other organization with which I am
> associated either explicitly, implicitly, or by inference. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity with which I am affiliated nor those of the entities themselves.
>
> On Wed, Dec 30, 2015 at 12:50 PM, Fernando Nunes <domusonline@gmail.com>
> wrote:
>
> > This should work:
> >
> > SELECT
> >
> > t.txt
> > FROM
> >
> > sysmaster:sysopendb d, sysmaster:flags_text t
> > WHERE
> >
> > d.odb_sessionid = DBINFO('sessionid') AND
> >
> > d.odb_isolation = t.flags AND
> >
> > d.odb_iscurrent ='Y' AND
> >
> > t.tabname = 'sysopendb'
> >
> > I have the feeling that there was some catch, but I can't remember....
> > One thing I do remember is that some old versions didn't provide a
> complete
> > list (the flags_text table was not correctly populated).
> > You can encapsulate this in a SPL...
> >
> > Probably the catch is that I believe each open transaction can have it's
> > own isolation level and in ESQL/C you may handle multiple concurrent
> > transactions.... Not sure what the result will be with this method. But
> I'd
> > have to check if multiple transactions require different sessions.... I
> > don't think so, but Jonathan knows this better than anyone. I'd have to
> > check.
> >
> > It's not the first time this question is asked and I alwasy confuse
> myself
> > into thinking I've written an article about this. Each time I end up
> > finding that what I did was about finding out if we were in the middle
> of a
> > transaction. I've done that in C (server side funtion) but I couldn't
> find
> > a function that would tell me this.
> >
> > You could add an RFE for this... as an option for DBINFO() for
> example....
> > (actually I thought there was one already but I couldn't find it)
> > Regards.
> >
> > On Wed, Dec 30, 2015 at 5:19 PM, Jonathan Leffler <
> > jonathan.leffler@gmail.com> wrote:
> >
> > > On Wed, Dec 30, 2015 at 7:28 AM, CHUAN LU <luchuan@cn.ibm.com> wrote:
> > >
> > > > please see the subject.
> > > >
> > >
> > > Please don't make us see the subject repeat the question in the body of
> > > the email.
> > >
> > > > How to know the current isolation level in ESQL/C?
> > >
> > > AFAIK, there isn't a way to discover the isolation level in ESQL/C; you
> > > have to know it by tracking it yourself. You need to use a function (or
> > > something similar) that tracks the current isolation level, and use
> that
> > > whenever you change the isolation level.
> > >
> > > Note that isolation level is really something the server handles and
> > > tracks; it really doesn't affect the ESQL/C at all. If you're really
> > > desparate, you could probably arrange to run 'onstat' and discover the
> > > information from one of its outputs, but that's downright tricky to do
> if
> > > the server is on a different machine from the ESQL/C code.
> > >
> > > --
> > > Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
> > > Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
> > > "Blessed are we who can laugh at ourselves, for we shall never cease to
> > be
> > > amused."
> > >
> > > --001a113f8264a401f6052820bb7e
> > >
> > >
> > >
> > >
> >
> >
>
>
*******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --
> > Fernando Nunes
> > Portugal
> >
> > http://informix-technology.blogspot.com
> > My email works... but I don't check it frequently...
> >
> > --089e01229aaa1881210528212c7f
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --001a1141f3e25b75620528219fa2
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--047d7bdc14e6d173f9052821b41a
Best he can do is my original post - to infer the default isolation from
the database's logging mode and try to keep track after that.
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Wed, Dec 30, 2015 at 1:28 PM, Fernando Nunes <domusonline@gmail.com>
wrote:
> Yes... But the question was about the "current" isolation level... I assume
> the OP needs this because within a function it may need to change it, but
> then restore the original.
> But he didn't explain it...
>
> On Wed, Dec 30, 2015 at 6:22 PM, Art Kagel <art.kagel@gmail.com> wrote:
>
> > Fernando:
> >
> > It's even funkier than you think:
> >
> > 1. There is a default isolation level for the connection to the database.
> >
> > 2. A change in isolation level MAY or MAY NOT affect existing cursors
> >
> > and transactions.
> >
> > 3. Multiple transactions could be started under different isolation
> >
> > levels.
> >
> > 4. The effective isolation level for a distributed or remote transaction
> >
> > may have nothing to do with the isolation level for the session that owns
> >
> > the transaction since its isolation may be based on the connected
> database
> >
> > while the transaction's effective isolaton level for the remote or
> >
> > distributed transaction may depend on those of the remote database(s)
> being
> >
> > accessed.
> >
> > It is a hairball.
> >
> > Art
> >
> > Art S. Kagel, President and Principal Consultant
> > ASK Database Management
> > www.askdbmgt.com
> >
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and do not reflect on the IIUG, nor any other organization with which I
> am
> > associated either explicitly, implicitly, or by inference. Neither do
> > those opinions reflect those of other individuals affiliated with any
> > entity with which I am affiliated nor those of the entities themselves.
> >
> > On Wed, Dec 30, 2015 at 12:50 PM, Fernando Nunes <domusonline@gmail.com>
> > wrote:
> >
> > > This should work:
> > >
> > > SELECT
> > >
> > > t.txt
> > > FROM
> > >
> > > sysmaster:sysopendb d, sysmaster:flags_text t
> > > WHERE
> > >
> > > d.odb_sessionid = DBINFO('sessionid') AND
> > >
> > > d.odb_isolation = t.flags AND
> > >
> > > d.odb_iscurrent ='Y' AND
> > >
> > > t.tabname = 'sysopendb'
> > >
> > > I have the feeling that there was some catch, but I can't remember....
> > > One thing I do remember is that some old versions didn't provide a
> > complete
> > > list (the flags_text table was not correctly populated).
> > > You can encapsulate this in a SPL...
> > >
> > > Probably the catch is that I believe each open transaction can have
> it's
> > > own isolation level and in ESQL/C you may handle multiple concurrent
> > > transactions.... Not sure what the result will be with this method. But
> > I'd
> > > have to check if multiple transactions require different sessions.... I
> > > don't think so, but Jonathan knows this better than anyone. I'd have to
> > > check.
> > >
> > > It's not the first time this question is asked and I alwasy confuse
> > myself
> > > into thinking I've written an article about this. Each time I end up
> > > finding that what I did was about finding out if we were in the middle
> > of a
> > > transaction. I've done that in C (server side funtion) but I couldn't
> > find
> > > a function that would tell me this.
> > >
> > > You could add an RFE for this... as an option for DBINFO() for
> > example....
> > > (actually I thought there was one already but I couldn't find it)
> > > Regards.
> > >
> > > On Wed, Dec 30, 2015 at 5:19 PM, Jonathan Leffler <
> > > jonathan.leffler@gmail.com> wrote:
> > >
> > > > On Wed, Dec 30, 2015 at 7:28 AM, CHUAN LU <luchuan@cn.ibm.com>
> wrote:
> > > >
> > > > > please see the subject.
> > > > >
> > > >
> > > > Please don't make us see the subject repeat the question in the body
> of
> > > > the email.
> > > >
> > > > > How to know the current isolation level in ESQL/C?
> > > >
> > > > AFAIK, there isn't a way to discover the isolation level in ESQL/C;
> you
> > > > have to know it by tracking it yourself. You need to use a function
> (or
> > > > something similar) that tracks the current isolation level, and use
> > that
> > > > whenever you change the isolation level.
> > > >
> > > > Note that isolation level is really something the server handles and
> > > > tracks; it really doesn't affect the ESQL/C at all. If you're really
> > > > desparate, you could probably arrange to run 'onstat' and discover
> the
> > > > information from one of its outputs, but that's downright tricky to
> do
> > if
> > > > the server is on a different machine from the ESQL/C code.
> > > >
> > > > --
> > > > Jonathan Leffler <jonathan.leffler@gmail.com> #include
> <disclaimer.h>
> > > > Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
> > > > "Blessed are we who can laugh at ourselves, for we shall never cease
> to
> > > be
> > > > amused."
> > > >
> > > > --001a113f8264a401f6052820bb7e
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
*******************************************************************************
> > > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > > >
> > > >
> > >
> > > --
> > > Fernando Nunes
> > > Portugal
> > >
> > > http://informix-technology.blogspot.com
> > > My email works... but I don't check it frequently...
> > >
> > > --089e01229aaa1881210528212c7f
> > >
> > >
> > >
> > >
> >
> >
>
>
*******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --001a1141f3e25b75620528219fa2
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --047d7bdc14e6d173f9052821b41a
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--089e011602a8690356052822258d
That could mean lots of changes in the application.... can't see why the
query wouldn't work...
On Wed, Dec 30, 2015 at 7:00 PM, Art Kagel <art.kagel@gmail.com> wrote:
> Best he can do is my original post - to infer the default isolation from
> the database's logging mode and try to keep track after that.
>
> Art
>
> Art S. Kagel, President and Principal Consultant
> ASK Database Management
> www.askdbmgt.com
>
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on the IIUG, nor any other organization with which I am
> associated either explicitly, implicitly, or by inference. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity with which I am affiliated nor those of the entities themselves.
>
> On Wed, Dec 30, 2015 at 1:28 PM, Fernando Nunes <domusonline@gmail.com>
> wrote:
>
> > Yes... But the question was about the "current" isolation level... I
> assume
> > the OP needs this because within a function it may need to change it, but
> > then restore the original.
> > But he didn't explain it...
> >
> > On Wed, Dec 30, 2015 at 6:22 PM, Art Kagel <art.kagel@gmail.com> wrote:
> >
> > > Fernando:
> > >
> > > It's even funkier than you think:
> > >
> > > 1. There is a default isolation level for the connection to the
> database.
> > >
> > > 2. A change in isolation level MAY or MAY NOT affect existing cursors
> > >
> > > and transactions.
> > >
> > > 3. Multiple transactions could be started under different isolation
> > >
> > > levels.
> > >
> > > 4. The effective isolation level for a distributed or remote
> transaction
> > >
> > > may have nothing to do with the isolation level for the session that
> owns
> > >
> > > the transaction since its isolation may be based on the connected
> > database
> > >
> > > while the transaction's effective isolaton level for the remote or
> > >
> > > distributed transaction may depend on those of the remote database(s)
> > being
> > >
> > > accessed.
> > >
> > > It is a hairball.
> > >
> > > Art
> > >
> > > Art S. Kagel, President and Principal Consultant
> > > ASK Database Management
> > > www.askdbmgt.com
> > >
> > > Blog: http://informix-myview.blogspot.com/
> > >
> > > Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> > > and do not reflect on the IIUG, nor any other organization with which I
> > am
> > > associated either explicitly, implicitly, or by inference. Neither do
> > > those opinions reflect those of other individuals affiliated with any
> > > entity with which I am affiliated nor those of the entities themselves.
> > >
> > > On Wed, Dec 30, 2015 at 12:50 PM, Fernando Nunes <
> domusonline@gmail.com>
> > > wrote:
> > >
> > > > This should work:
> > > >
> > > > SELECT
> > > >
> > > > t.txt
> > > > FROM
> > > >
> > > > sysmaster:sysopendb d, sysmaster:flags_text t
> > > > WHERE
> > > >
> > > > d.odb_sessionid = DBINFO('sessionid') AND
> > > >
> > > > d.odb_isolation = t.flags AND
> > > >
> > > > d.odb_iscurrent ='Y' AND
> > > >
> > > > t.tabname = 'sysopendb'
> > > >
> > > > I have the feeling that there was some catch, but I can't
> remember....
> > > > One thing I do remember is that some old versions didn't provide a
> > > complete
> > > > list (the flags_text table was not correctly populated).
> > > > You can encapsulate this in a SPL...
> > > >
> > > > Probably the catch is that I believe each open transaction can have
> > it's
> > > > own isolation level and in ESQL/C you may handle multiple concurrent
> > > > transactions.... Not sure what the result will be with this method.
> But
> > > I'd
> > > > have to check if multiple transactions require different
> sessions.... I
> > > > don't think so, but Jonathan knows this better than anyone. I'd have
> to
> > > > check.
> > > >
> > > > It's not the first time this question is asked and I alwasy confuse
> > > myself
> > > > into thinking I've written an article about this. Each time I end up
> > > > finding that what I did was about finding out if we were in the
> middle
> > > of a
> > > > transaction. I've done that in C (server side funtion) but I couldn't
> > > find
> > > > a function that would tell me this.
> > > >
> > > > You could add an RFE for this... as an option for DBINFO() for
> > > example....
> > > > (actually I thought there was one already but I couldn't find it)
> > > > Regards.
> > > >
> > > > On Wed, Dec 30, 2015 at 5:19 PM, Jonathan Leffler <
> > > > jonathan.leffler@gmail.com> wrote:
> > > >
> > > > > On Wed, Dec 30, 2015 at 7:28 AM, CHUAN LU <luchuan@cn.ibm.com>
> > wrote:
> > > > >
> > > > > > please see the subject.
> > > > > >
> > > > >
> > > > > Please don't make us see the subject repeat the question in the
> body
> > of
> > > > > the email.
> > > > >
> > > > > > How to know the current isolation level in ESQL/C?
> > > > >
> > > > > AFAIK, there isn't a way to discover the isolation level in ESQL/C;
> > you
> > > > > have to know it by tracking it yourself. You need to use a function
> > (or
> > > > > something similar) that tracks the current isolation level, and use
> > > that
> > > > > whenever you change the isolation level.
> > > > >
> > > > > Note that isolation level is really something the server handles
> and
> > > > > tracks; it really doesn't affect the ESQL/C at all. If you're
> really
> > > > > desparate, you could probably arrange to run 'onstat' and discover
> > the
> > > > > information from one of its outputs, but that's downright tricky to
> > do
> > > if
> > > > > the server is on a different machine from the ESQL/C code.
> > > > >
> > > > > --
> > > > > Jonathan Leffler <jonathan.leffler@gmail.com> #include
> > <disclaimer.h>
> > > > > Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
> > > > > "Blessed are we who can laugh at ourselves, for we shall never
> cease
> > to
> > > > be
> > > > > amused."
> > > > >
> > > > > --001a113f8264a401f6052820bb7e
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
*******************************************************************************
> > > > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > > > >
> > > > >
> > > >
> > > > --
> > > > Fernando Nunes
> > > > Portugal
> > > >
> > > > http://informix-technology.blogspot.com
> > > > My email works... but I don't check it frequently...
> > > >
> > > > --089e01229aaa1881210528212c7f
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
*******************************************************************************
> > > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > > >
> > > >
> > >
> > > --001a1141f3e25b75620528219fa2
> > >@