Informix

 View Only
  • 1.  zombie SQLERR 349

    Posted Mon March 22, 2021 04:02 PM
    Hi,

    I am checking several connections with error 349 in several instances over versions 12.10.xx and 14.10.xx, the strange thing is that sessions appear in syssessions ...!!!
    As the error 349 is related to missing database selection. I am trying to identify the cause.
    Has anyone had a similar problem? How can I identify what was at the origin of this failure?

    Thanks for any help,

    SP

    ------------------------------
    Sergio Peres
    AIRC
    Coimbra
    ------------------------------

    #Informix


  • 2.  RE: zombie SQLERR 349

    Posted Tue March 23, 2021 04:27 AM
    Hi,

    maybe "onstat -g ses <session id>" can give you a bit more information.

    Most likely, this is an application or user error, basically what the error description says:

    -349  Database not selected yet.

    This statement cannot be executed because no current database exists.
    Either no current database has been established yet, or the current
    database was closed with a CLOSE DATABASE statement. You execute the
    DATABASE or CREATE DATABASE statement to establish a current database.

    It is possible to connect to a server without specifying a database. For such a connection,
    you will see an entry in the syssessions table or in the output of "onstat -g ses".
    "onstat -g ses <session id>" consequently shows that no database is established.

    To further figure out, what such a session did to get itself into this situation, is a bit difficult
    on the server side. The only thing that comes to my mind is to activate SQLTRACE to be
    able to see, what the session did before it received the error ... But activating SQLTRACE for
    everybody in a production environment may not be desirable. It may be possible
    to create a sysdbopen procedure for a specific database user who receives the error,
    and then activate the SQL tracing in that sysdbopen procedure just for that user.
    Check the documentation for details about the sysdbopen procedure and how to use
    the "set environment" statement to enable SQL tracing for a a session.

    Regards,
    Martin

    --

    Martin Fuerderer

    Software Engineer, Software Development

    HCL Technologies Ltd.

    Frankfurter Ring 17

    80807 Munich, Germany

    www.hcltech.com


    ::DISCLAIMER::

    The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.






  • 3.  RE: zombie SQLERR 349

    Posted Tue March 23, 2021 04:40 AM
    >>How can I identify what was at the origin of this failure?
    You can use CLIENT_LABEL parameter to track your session. Provided you are using IDS/CSDK/JDBC version which supports CLIENT_LABEL option or set CLIENT_LABEL as environment variable and make sure your IDS version supports CLIENT_LABEL. Couple of links below for more information on CLIENT_LABEL:


    http://www.hcl-informix-user.com/blogs/easier-client-sessions-tracking

    https://www.imwuc.org/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=36c408f9-f54d-88e8-c247-39c6f58e67f9&forceDialog=0

    Hope this helps

    Thanks
    -Shesh


    ------------------------------
    Sheshnarayan Agrawal
    ------------------------------



  • 4.  RE: zombie SQLERR 349

    Posted Tue March 23, 2021 09:55 AM
    Thanks for reply Shes,

    Concerning we use older versions of CSDK and JDBC we don't have chance to use this feature.

    Regards,

    SP

    ------------------------------
    Sergio Peres
    AIRC
    Coimbra
    ------------------------------



  • 5.  RE: zombie SQLERR 349

    Posted Tue March 23, 2021 09:51 AM
    Thanks for reply Martin,

    My problem is that we use the same login for all applications, the validations are done internally.
    Since in the cases that have appeared the SQL is different, we are having trouble identifying the source.

    Regards,

    SP

    ------------------------------
    Sergio Peres
    AIRC
    Coimbra
    ------------------------------



  • 6.  RE: zombie SQLERR 349

    Posted Tue March 23, 2021 09:52 AM
    Thanks for reply Martin,

    My problem is that we use the same login for all applications, the validations are done internally.
    Since in the cases that have appeared the SQL is different, we are having trouble identifying the source.

    Best Regards,

    SP

    ------------------------------
    Sergio Peres
    AIRC
    Coimbra
    ------------------------------



  • 7.  RE: zombie SQLERR 349

    IBM Champion
    Posted Tue March 23, 2021 05:13 AM
    Trapping the error should provide you with (an af file containing) an 'onstat -g ses <sid>' output which then would show things like
    • user
    • client host
    • client application
    • current + last parsed SQL statement
    Here's what to do:
    • onstat -g cfg DUMPSHMEM  (shmem dumping on?)
    • onmode -wm DUMPSHMEM=0   (temporarily turn it off, shmem not needed for this purpose)
    • onmode -I 349  (turn on the trap)
    • onstat -g ras       (to verify the trap is on/shmem dumping off)
    • wait until error occurs (or af file(s) got created)
    • onmode -I    (disable the trap)
    • onmode -wm DUMPSHMEM=<orig_value>  (turn shmem dumping back on, if necessary)
    • evaluate af files mentioned in message log (look for 'onstat -g ses <sid>'; also be aware that same af file could contain multiple assertions if same db server thread incurred the assertion multiple times.)


    ------------------------------
    Andreas Legner
    ------------------------------



  • 8.  RE: zombie SQLERR 349

    Posted Tue March 23, 2021 09:59 AM
    Thanks for reply and suggestion Andreas,

    This can help to identify the source machine, I will test it.

    Best Regards,

    SP


    ------------------------------
    Sergio Peres
    AIRC
    Coimbra
    ------------------------------