libopendbx-devel — Help and discussion about OpenDBX

Re: [opendbx] MySQL unsupported data types

[Brad <bss...@gm...>]

It is frustrating that there really is no such thing as ANSI standard SQL from virtually any of the database vendors.  I understand your desire to provide some semblance of ANSI standard and I applaud you for your efforts. 

Would you be open to creating  a new more inclusive "odbx_column_type_nonansi" function that does provide full support for each type? This way each user could choose to use either ANSI support or non-ANSI support for types.  

Brad Selfridge
913-269-2385

> On Oct 31, 2014, at 2:07 AM, Norbert Sendetzky <no...@li...> wrote:
> 
> Hi Brad
> 
>> I've researched the OpenDBX source files and have found that not
>> all column types are being returned. It seems most databases
>> supported have this anomaly. I'm curious as to why?
>> 
>> It doesn't make sense to me why each database interface program 
>> wouldn't support all types  for that database. I must not
>> understand something. Please educate me.
> 
> OpenDBX supports the ANSI data types which have a defined format and
> semantics. Database vendors invented much more data types for special
> cases which doesn't fit into the ANSI scheme. These special data types
> are summarized as TYPE_UNKNOWN in OpenDBX which only means that they
> doesn't fit into the existing ANSI types and their data is returned in
> its native format without any conversion. So TYPE_UNKNOWN is only
> another data type for all remaining database specific types.
> 
> 
> Norbert
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX

Re: [opendbx] MySQL unsupported data types

[Norbert S. <no...@li...>]

Hi Brad

> I've researched the OpenDBX source files and have found that not
> all column types are being returned. It seems most databases
> supported have this anomaly. I'm curious as to why?
> 
> It doesn't make sense to me why each database interface program 
> wouldn't support all types  for that database. I must not
> understand something. Please educate me.

OpenDBX supports the ANSI data types which have a defined format and
semantics. Database vendors invented much more data types for special
cases which doesn't fit into the ANSI scheme. These special data types
are summarized as TYPE_UNKNOWN in OpenDBX which only means that they
doesn't fit into the existing ANSI types and their data is returned in
its native format without any conversion. So TYPE_UNKNOWN is only
another data type for all remaining database specific types.


Norbert

Re: [opendbx] MySQL unsupported data types

[Brad S. <bss...@gm...>]

I've researched the OpenDBX source files and have found that not all column types are being returned. It seems most databases supported have this anomaly. I'm curious as to why?

 It doesn't make sense to me why each database interface program wouldn't support all types  for that database. I must not understand something. Please educate me. 

Thanks, 

Brad Selfridge


> On Oct 28, 2014, at 1:23 PM, Norbert Sendetzky <no...@li...> wrote:
> 
> Hi Brad
> 
>> I'm using an ORM framework. It tries to generate the appropriate 
>> object of the data value using the returned data type.  No type,
>> no object. My only option would be to tear into the framework and 
>> bypass/override a lot of code, thereby potentially nullifying the 
>> need of the framework.
> 
> The best option might be if the ORM framework would provide all
> unknown data types as string or binary data. Then you would be at
> least able to access the data and transform it afterwards if necessary.
> 
> 
> Norbert
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX

Re: [opendbx] MySQL unsupported data types

[Brad <bss...@gm...>]

So, are you saying that OpenDBX does not/cannot always return the column types for tables? 

Brad Selfridge
913-269-2385

> On Oct 28, 2014, at 1:23 PM, Norbert Sendetzky <no...@li...> wrote:
> 
> Hi Brad
> 
>> I'm using an ORM framework. It tries to generate the appropriate 
>> object of the data value using the returned data type.  No type,
>> no object. My only option would be to tear into the framework and 
>> bypass/override a lot of code, thereby potentially nullifying the 
>> need of the framework.
> 
> The best option might be if the ORM framework would provide all
> unknown data types as string or binary data. Then you would be at
> least able to access the data and transform it afterwards if necessary.
> 
> 
> Norbert
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX

Re: [opendbx] MySQL unsupported data types

[Norbert S. <no...@li...>]

Hi Brad

> I'm using an ORM framework. It tries to generate the appropriate 
> object of the data value using the returned data type.  No type,
> no object. My only option would be to tear into the framework and 
> bypass/override a lot of code, thereby potentially nullifying the 
> need of the framework.

The best option might be if the ORM framework would provide all
unknown data types as string or binary data. Then you would be at
least able to access the data and transform it afterwards if necessary.


Norbert

Re: [opendbx] MySQL unsupported data types

[Brad <bss...@gm...>]

I'm using an ORM framework. It tries to generate the appropriate object of the data value using the returned data type.  No type, no object. My only option would be to tear into the framework and bypass/override a lot of code, thereby potentially nullifying the need of the framework. 

I guess I'm mystified why there are types not returned. Other tools show/return them?  Please enlighten me. 

Brad Selfridge
913-269-2385

> On Oct 28, 2014, at 6:20 AM, Norbert <no...@li...> wrote:
> 
> Hi Brad
> 
> I don't know the Smalltalk implementation but OpenDBX still returns the value when you call opendbx_field_value() even if the exact type is unknown.
> 
> For MySQL timestamps it's a string representation of an integer value. If you know that your column is a timestamp, you can use it as such in your application.
> 
> 
> Norbert
> 
> 
> Brad Selfridge <bss...@gm...> schrieb:
> 
>> I am trying to convert an application to Smalltalk and the MySQL database is riddled with timestamp column types. However, OpenDbx returns an unsupported data type for time stamps. It is impossible to convert the column type to DateTime. Is there any possibility of adding timestamp as a supported type for Mysql?
>> 
>> Brad Selfridge
>> 
>> Sent from my iPad
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> libopendbx-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
>> http://www.linuxnetworks.de/doc/index.php/OpenDBX
> ------------------------------------------------------------------------------
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX

Re: [opendbx] MySQL unsupported data types

[Norbert <no...@li...>]

Hi Brad

I don't know the Smalltalk implementation but OpenDBX still returns the value when you call opendbx_field_value() even if the exact type is unknown.

For MySQL timestamps it's a string representation of an integer value. If you know that your column is a timestamp, you can use it as such in your application.


Norbert


Brad Selfridge <bss...@gm...> schrieb:

>I am trying to convert an application to Smalltalk and the MySQL database is riddled with timestamp column types. However, OpenDbx returns an unsupported data type for time stamps. It is impossible to convert the column type to DateTime. Is there any possibility of adding timestamp as a supported type for Mysql?
>
>Brad Selfridge
>
>Sent from my iPad
>------------------------------------------------------------------------------
>_______________________________________________
>libopendbx-devel mailing list
>lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
>http://www.linuxnetworks.de/doc/index.php/OpenDBX

[opendbx] MySQL unsupported data types

[Brad S. <bss...@gm...>]

I am trying to convert an application to Smalltalk and the MySQL database is riddled with timestamp column types. However, OpenDbx returns an unsupported data type for time stamps. It is impossible to convert the column type to DateTime. Is there any possibility of adding timestamp as a supported type for Mysql?

Brad Selfridge

Sent from my iPad

[opendbx] New doxygen 1.8.8 default FileParser causes man page generation failure

[Scott K. <de...@ki...>]

Doxygen has, again, made a backward incompatible API change.  It has a new 
default FileParser which won't parse lib/opendbx/api.  For Debian, I added a 
link do lib/opendbx/api.dox (so the correct FileParser is chosen) and updated 
doc/Doxfile.in.  I didn't actually rename lib/opendbx/api since that would have 
meant messing with the libopendbx makefiles.

FYI.

Scott K

Re: [opendbx] ODBC Connection String

[Guillermo P. <gui...@gm...>]

The options are the ones you find here:

http://www.linuxnetworks.de/doc/index.php/OpenDBX/Configuration#odbc_backend

But... "dns less"? host less you mean? I don't know much about odbc, just
know the minimum to configure and make the tests run :).

Guille


On Wed, May 7, 2014 at 3:18 PM, Mariano Martinez Peck <mar...@gm...
> wrote:

> I don't remember. Maybe here is some help:
> http://forum.world.st/Coming-here-from-the-Pharo-mailing-list-td4641683.html ?
>
> Maybe Norbert (OpenDBX author) knows. Did you try specifying all the
> DBXConnectionSettings with the database, username and password?
>
> Best,
>
> On Sun, May 4, 2014 at 7:36 PM, Jose Sebastian Calvo <fxg...@gm...>wrote:
>
>> Hi,
>>
>> I've read that the preferred method in windows to use MSSQLServer is
>> trough odbc.
>> In Dolphin Smalltalk I can use a connection string to do a "dns less"
>> connection so there is no need to define an specific DNS in the windows dns
>> manager.
>> e.g. 'UID=my_uid;PWD=my_pwd;DATADABE=my_database'
>>
>> Is there a way to do the same with DBXTalk?
>>
>> Regards
>>   Sebastian Calvo
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DBXTalk" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to dbx...@go....
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "DBXTalk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dbx...@go....
> For more options, visit https://groups.google.com/d/optout.
>

Re: [opendbx] ODBC Connection String

[Mariano M. P. <mar...@gm...>]

I don't remember. Maybe here is some help:
http://forum.world.st/Coming-here-from-the-Pharo-mailing-list-td4641683.html ?

Maybe Norbert (OpenDBX author) knows. Did you try specifying all the
DBXConnectionSettings with the database, username and password?

Best,

On Sun, May 4, 2014 at 7:36 PM, Jose Sebastian Calvo <fxg...@gm...>wrote:

> Hi,
>
> I've read that the preferred method in windows to use MSSQLServer is
> trough odbc.
> In Dolphin Smalltalk I can use a connection string to do a "dns less"
> connection so there is no need to define an specific DNS in the windows dns
> manager.
> e.g. 'UID=my_uid;PWD=my_pwd;DATADABE=my_database'
>
> Is there a way to do the same with DBXTalk?
>
> Regards
>   Sebastian Calvo
>
> --
> You received this message because you are subscribed to the Google Groups
> "DBXTalk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dbx...@go....
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Mariano
http://marianopeck.wordpress.com

Re: [opendbx] /dev/urandom file descritpors left open, libopendbx-devel Digest, Vol 49, Issue 1

[Norbert S. <no...@li...>]

Hi Adam

> 2)      We were having major issues with the C++ API crashing the 
> application when connection objects went out of scope:

Did you make a test without using the copy constructor like I've
suggested?

OpenDBX::Conn GetAllTxFileDb = Conn( "mssql", "172.16.232.60", "" );

> 3)      We are calling into the library from multiple POSIX
> threads so we MUTEX'ed these calls to allow only one thread at a
> time accesses the library.  I do not think this is necessary as
> your documentation states it is thread-safe however we decided to
> do this as an extra precaution.

Not every backend is thread-safe but the MSSQL backend is. You can
test thread-safety with

odbx_get_option( handle, ODBX_OPT_THREAD_SAFE, &value );

Would be interesting if you could find out if using one connection per
thread is really thread-safe for the MSSQL backend. This could speed
up your application a lot! Remember that in this case you need to call
odbx_init(), odbx_bind(), ..., odbx_unbind() and odbx_finish() in each
thread.

Best regards,


Norbert

Re: [opendbx] /dev/urandom file descritpors left open, libopendbx-devel Digest, Vol 49, Issue 1

[Levine, A. <AL...@gl...>]

Norbert,

Let me first apologize for submitting a new e-mail each time I post as opposed to adding to the existing thread.
I have read-only capability on the web site, or I have not yet figured out how to add to a thread through the WEB site.
https://sourceforge.net/p/libopendbx/mailman/message/31896656/

It has been quite some time since I updated this thread, I wanted to be sure we had something pertinent to report.
We have found a couple work-arounds for our issues and have been running many hundreds to thousands of tests (tens of thousands of DB accesses) with very satisfactory results.
I would like to share with you these work-arounds as they may help future users of OpenDBX or you may have further comments for us.


1)       The file descriptors being left open seems to be related to the freeetds version specified in the  /etc/freetds/freeetd.conf file.  We were using tds_version = 8.0, when we go down to tds_version = 7.0 our open descriptor problems went away.  BTW, we also specify client charset = UTF-8 in the file.

2)      We were having major issues with the C++ API crashing the application when connection objects went out of scope:

a.      "if we call finish(), then when the function exits Result::~Result() crashes the application as seg fault on the delete m_impl statement"
We decided to abandon using the C++ API and switched over to using the C API calls within our C++ application.  This solved many issues we were having with the C++ objects.  I am not sure if it is our lack of understanding of the C++ usage, the C++ API in relation to freetds and/or MS SQL, or simply bugs within the C++ API.  Either way once we made this change things stabilized.

3)      We are calling into the library from multiple POSIX threads so we MUTEX'ed these calls to allow only one thread at a time accesses the library.  I do not think this is necessary as your documentation states it is thread-safe however we decided to do this as an extra precaution.

I appreciate your time and patience and want to thank you again for creating OpenDBX.

Regards,

Adam


____________________________________________________________
This e-mail (including attached documents) may contain confidential or proprietary
information intended only for use by the named recipient(s). Use by persons
other than the named recipient(s), further dissemination, or copying of this
email is prohibited unless authorized by the sender.

Re: [opendbx] /dev/urandom file descritpors left open, libopendbx-devel Digest, Vol 49, Issue 1

[Norbert S. <no...@li...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Adam

> // Norbert, if this object is declared here then each call to this
> function // leaves a /dev/urandom file descriptor open.  Making it
> global leaves only // a single file descriptor open. #ifndef
> USE_GLOBAL_DB_OBJECT OpenDBX::Conn GetAllTxFileDb; #endif 
> PTR_COLUMN_NAME_POS_PAIR pNameCol = NULL;
> 
> try { GetAllTxFileDb = Conn( "mssql", "172.16.232.60", "" );

Doesn't it crash if you remove the try/catch here and write

OpenDBX::Conn GetAllTxFileDb = Conn( "mssql", "172.16.232.60", "" );

instead? If it works, than the code in the copy constructors creates
the problem because you are creating an empty object first and copying
an initialized object into that afterwards.


Norbert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS6DHnAAoJEA3e3tWv2uU+ux0P/0HFFhY7IySP8ljR6ZJyBFZ2
JDuPb0Xe1COF4ILv4BXik5t84X0isb6v+AyQ4UFLwgVBsJU6OS8TtiNjooC0ZH0p
b41U3YxWjr1w3HIg7nv4ZC9bXRCUG2HdZFRxVLlivA5dMobanAG+z5Engo+UC//I
Lzz3wYeokTMNZQnOpor1e+huo3TnN3N7M7SI2GSYFLmczd1oAMeVKwxh1U/t2ig+
IRHJF0xOLbL8L9OYe49O4LGcv33gRBXim2Pe/uG/jmF31c2ePkQsJS2/XcsXSPrD
Jh1M166QQRcHze190x715kSYKUc5RJ0CNYFZuPeMY/539HjPm6UVmZ7/L89cQ2Eb
R41OlHkrJc3W1L05l44hODIpO4sqRRXc+y254ALFFfDJT6iZbSuxSRIANDcX8VE0
QRD11HqpOAhwDGr3K6wy6djttKQIMQ2b7b9g56OMsdtCUl/nTrQ0QDoyyexjyhPv
G08Isv8B/LeMjK4IWvVyJUajl+zqJKbLFrBEMJ08Egg65ZIMy6NG51co7rWXbbld
CX6txJN2I067xiOCeOnDRWERS89hgOmgqqUOHeM94aVJIeIcIi3sg/8aCYuUJrtb
PVKsTZerOsrUZuGFxfsJn3KPEdiNdHcLWXIQlOphSQ5S4X9l5FZWV5fYQW8Huhm3
ghutwPPtZJPNBhKo/3X8
=rgQB
-----END PGP SIGNATURE-----

Re: [opendbx] /dev/urandom file descritpors left open, libopendbx-devel Digest, Vol 49, Issue 1

[Levine, A. <AL...@gl...>]

Norbert,

BTW, I ran 1,000,000 rapid fire select statements yesterday using a global/static
OpenDBX::Conn object and did not crash.  As stated when using a global object
only one /dev/urandom file descriptor is opened and left open.

Regarding Conn::finish() the
Test function with crash on Result::~Result() is below.

void TestMsSqlGetAllTxFileTransmissions()
{

// Norbert, if this object is declared here then each call to this function
// leaves a /dev/urandom file descriptor open.  Making it global leaves only
// a single file descriptor open.
#ifndef  USE_GLOBAL_DB_OBJECT
OpenDBX::Conn GetAllTxFileDb;
#endif
PTR_COLUMN_NAME_POS_PAIR pNameCol = NULL;

    try
    {
        GetAllTxFileDb = Conn( "mssql", "172.16.232.60", "" );
        GetAllTxFileDb.bind("MediaServerTest1", "test1admin", "ponyexpress", ODBX_BIND_SIMPLE );
        std::cout << "Initialized connection" << std::endl;
    }
    catch( std::exception &e )
    {
     std::cerr << "Caught exception: " << e.what() << std::endl;
        return;
    }


OpenDBX::Result DbRslt = GetAllTxFileDb.create( DbStoredProcGetAllSchedFileTransmissions ).execute();

odbxres RsltStat;

int RowCnt = 0;

while( ( RsltStat = DbRslt.getResult() ) != ODBX_RES_DONE )
{
  // used to map column names and positions
  pNameCol = NULL;
  switch( RsltStat )
  {
   case ODBX_RES_TIMEOUT:
    // NOTE: Retrieving the result is not (!) canceled
    continue;
   case ODBX_RES_NOROWS:
    continue;
     // case ODBX_RES_ROWS:
     default:
      break;
  }

  while(DbRslt.getRow() != ODBX_ROW_DONE )
  {
   if((DbRslt.columnCount() > 0) && (DbRslt.fieldLength(0) > 0))
   {
    if(DbRslt.columnName(0).c_str()[0] == '@')
    {
     std::cout << "\nPRINTING STATUS TABLE\n";
     // Processing a return/status "table" not the desired data table
     if(pNameCol == NULL)
     {
      pNameCol = (PTR_COLUMN_NAME_POS_PAIR)&gAllSchFileTxStatusMap;
      // first time through map the column names and positions
      FillColNamePosPairs(DbRslt, pNameCol, (sizeof(DB_ALL_SCHED_FILE_TX_STATUS_MAPPINGS)/sizeof(COLUMN_NAME_POS_PAIR)));
     }
     // Just print it out for example
     if((gAllSchFileTxStatusMap.ReturnValue.Pos != -1) && (DbRslt.fieldLength(gAllSchFileTxStatusMap.ReturnValue.Pos) != 0))
     {
      std::cout << gAllSchFileTxStatusMap.ReturnValue.Name << ": "
          << DbRslt.fieldValue(gAllSchFileTxStatusMap.ReturnValue.Pos) << std::endl;
     }
     else
     {
      std::cout << gAllSchFileTxStatusMap.ReturnValue.Name << ":" << endl;
     }
     if((gAllSchFileTxStatusMap.StatusText.Pos != -1) && (DbRslt.fieldLength(gAllSchFileTxStatusMap.StatusText.Pos) != 0))
     {
      // Just print it out
      std::cout << gAllSchFileTxStatusMap.StatusText.Name << ": "
          << DbRslt.fieldValue(gAllSchFileTxStatusMap.StatusText.Pos) << std::endl;
     }
     else
     {
      std::cout << gAllSchFileTxStatusMap.StatusText.Name << ":" << endl;
     }
    }
    else
    {
     // Getting the "main" desired table
     std::cout << "\nPRINTING DESIRED TABLE ROW INDEX " << RowCnt++ << std::endl;
     if(pNameCol == NULL)
     {
      pNameCol = (PTR_COLUMN_NAME_POS_PAIR)&gAllSchFileTxMap;
      // first time through map the column names and positions
      FillColNamePosPairs(DbRslt, pNameCol, (sizeof(DB_ALL_SCHED_FILE_TX_MAPPINGS)/sizeof(COLUMN_NAME_POS_PAIR)));
     }
     // Just print it out for this example
     if((gAllSchFileTxMap.FileId.Pos != -1) && (DbRslt.fieldLength(gAllSchFileTxMap.FileId.Pos) != 0))
     {
      std::cout << gAllSchFileTxMap.FileId.Name << ": "
          << DbRslt.fieldValue(gAllSchFileTxMap.FileId.Pos) << endl;
     }
     if((gAllSchFileTxMap.ScheduleId.Pos != -1) && (DbRslt.fieldLength(gAllSchFileTxMap.ScheduleId.Pos) != 0))
     {
      std::cout << gAllSchFileTxMap.ScheduleId.Name << ": "
          << DbRslt.fieldValue(gAllSchFileTxMap.ScheduleId.Pos) << endl;
     }
    }
   }
  } // while ( DbRslt.getRow() != ODBX_ROW_DONE )
} // while( ( RsltStat = DbRslt.getResult() ) != ODBX_RES_DONE )
try
{
  DbRslt.finish();
}
catch( std::exception &e )
{
  std::cerr << "Caught exception: " << e.what() << std::endl;
  return;
}
try
{
  GetAllTxFileDb.unbind();
}
catch( std::exception &e )
{
  std::cerr << "Caught exception: " << e.what() << std::endl;
  return;
}
// Norbert, if we call finish(), then when function exits Result::~Result()
// crashes application as seg fault on the delete m_impl statement
// try
// {
//  GetAllTxFileDb.finish();
// }
// catch( std::exception &e )
// {
//  std::cerr << "Caught exception: " << e.what() << std::endl;
//  return;
// }

return;
}

Regards,

Adam

Hi Adam

> When we call Result::finish(), Conn::unbind(), Conn::finish() all
> three calls complete correctly, When the function is exited the
> OpenDBX::Result object goes out of scope and the destructor is
> called. In the destructor, OpenDBX::~Result(), the delete m_impl;
> crashes the application with a segmentation fault, I assume because
> the m_impl was already deleted in Conn::finish()?

The sequence of calls is correct.

Conn::finish() doesn't free any memory allocated in m_impl (which are
different across all object types, so Conn, Stmt and Result all use
their own m_impl variable with their own object types like Conn_Impl,
StmtSimple_Impl and Result_Impl).

I would assume that there might be a problem with the reference
counting. Do you use assignment for Result or the copy contructor like
Result result = myresult?


Norbert


____________________________________________________________
This e-mail (including attached documents) may contain confidential or proprietary
information intended only for use by the named recipient(s). Use by persons
other than the named recipient(s), further dissemination, or copying of this
email is prohibited unless authorized by the sender.

Re: [opendbx] /dev/urandom file descritpors left open, libopendbx-devel Digest, Vol 49, Issue 1

[Norbert S. <no...@li...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Adam

> When we call Result::finish(), Conn::unbind(), Conn::finish() all
> three calls complete correctly, When the function is exited the
> OpenDBX::Result object goes out of scope and the destructor is
> called. In the destructor, OpenDBX::~Result(), the delete m_impl;
> crashes the application with a segmentation fault, I assume because
> the m_impl was already deleted in Conn::finish()?

The sequence of calls is correct.

Conn::finish() doesn't free any memory allocated in m_impl (which are
different across all object types, so Conn, Stmt and Result all use
their own m_impl variable with their own object types like Conn_Impl,
StmtSimple_Impl and Result_Impl).

I would assume that there might be a problem with the reference
counting. Do you use assignment for Result or the copy contructor like
Result result = myresult?


Norbert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS55ceAAoJEA3e3tWv2uU+HQ8P/0AWSpc8v4tSsxXE9rQ6X+2x
lLio81FmifadBlpPz4N8XIeXAW+8O971rDTBT6B12ceiNwcUSMhGqI5Sfg/qCZBO
UQaEj+8et9ZEZhBUoNLLQszeSEyzIYCBVDfCFS2bWnwoAejD9Kngw+GRI9DpoHls
26kDlvTQKPACq6ptiyrLrjLXbS+RNPvGtQCtGJxQAMUpQBFQ3mJVUFCZUv7BHVKZ
TPSTp/TC4cQMPZ7vllrNo8EhCJcV/QAsu2yC8+muP4r5ecKuih5aDlM5T3P+YZdw
Nj7m/bloV28oQ5Eml/9DkBg9V5Y0XR2BsCBdgy4d8c07OfqPBfugAU9aZ9OhQTl3
Z1k8NWBkKLUZGWrzPGCfJiSx2+19iURekLT64XZ0NZVjgKFrwjxBXbB/XwTuC5EA
LTiITvsq++lQ8bfgm0HEPnW+M+zVMfmSbbVaUOuL+T7sAeT21QsqUQmkmgWwC566
Po/nI+1gDQbyyUmR1hQq6K3sao7Kz0393XQfE1ZVpt57ZEyohzxfKtqkyjb5oKRl
jHTYSxRDLXznzn4Ms0bzF/FAMR4wHhTd6uw0ypotRD1bIa5LzpF21jlSZtxzNCFD
NESlZsvInvkWr7VLc1it//VZwlGl80uvSu71pnjWfDV30WeQmCg8PUkfN8A6uc79
EAOnqeWuYvvDZmu7hjOX
=6TBS
-----END PGP SIGNATURE-----

[opendbx] /dev/urandom file descritpors left open, libopendbx-devel Digest, Vol 49, Issue 1

[Levine, A. <AL...@gl...>]

Norbert,

Thank you for your response.

I was thinking that it was not OpenDBX but perhaps the backend or FreeTDS, or even some other lower level driver.
We also connect to a PostGres database in another application but have yet to see this problem which reinforces it being below OpenDbx.
We do call Conn::unbind().
We found that if we call Conn::finish() the application crashes as follows:

If we call Result::finish(), Conn::unbind() no crash.
When we call Result::finish(), Conn::unbind(), Conn::finish() all three calls complete correctly, When the function is exited the OpenDBX::Result object goes out of scope and the destructor is called.
In the destructor, OpenDBX::~Result(), the delete m_impl; crashes the application with a segmentation fault, I assume because the m_impl was already deleted in Conn::finish()?

Back to the /dev/urandom open descriptor problem, another interesting finding is:
When we use a local OpenDBX::Conn object, (on stack) the file descriptor is not closed so each call to the function leaves another one open ultimately resulting in a "Too Many Open Files" crash.
However if we use a global (statically allocated) OpenDBX::Conn object there is only one /dev/urandom file descriptor left open.

I also did a test where I added the Conn::finish() call and then in OpenDBX::~Result() I used the debugger to skip over the delete m_impl; statement so the application doesn't crash.
The /dev/unrandom file descriptor is still left open for each call so I do not think a call to Conn::finish() would fix this issue.

Regards,

Adam


Hi Adam

> We are using OpenDbx (C++) with MSSQL, on Ubuntu 12.04. Our
> application is long running with many calls to the database. Our
> application uses a local OpenDBX::Conn object to connect (bind),
> retrieve result, finish results, unbind and then the local
> OpenDBX::Conn object goes out of scope when function returns.
>
> After a period of time our program crashes, with the usual error
> being "too many open files". Our process open file limit is the
> default 1024. After some debugging we found that a file descriptor
> to /dev/urandom is left open for each connection we made to the
> data base. Of course after roughly 1024 connections to the database
> the application crashes with the above error as would be expected.

/dev/urandom is not used by OpenDBX directly but I think by FreeTDS if
you are using the MSSQL backend.

> Has anyone experienced this? Is there a workaround or patch? Are
> we using the library correctly?

Can you please have a look if you call Conn::unbind() and
Conn::finish() before the objects go out of scope? This is important
as the cleanup can't be done by the destructor of the class.


Norbert


Adam


____________________________________________________________
This e-mail (including attached documents) may contain confidential or proprietary
information intended only for use by the named recipient(s). Use by persons
other than the named recipient(s), further dissemination, or copying of this
email is prohibited unless authorized by the sender.

Re: [opendbx] /dev/urandom file descritpors left open

[Norbert S. <no...@li...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Adam

> We are using OpenDbx (C++) with MSSQL, on Ubuntu 12.04. Our 
> application is long running with many calls to the database. Our 
> application uses a local OpenDBX::Conn object to connect (bind), 
> retrieve result, finish results, unbind and then the local 
> OpenDBX::Conn object goes out of scope when function returns.
> 
> After a period of time our program crashes, with the usual error 
> being "too many open files". Our process open file limit is the 
> default 1024. After some debugging we found that a file descriptor
> to /dev/urandom is left open for each connection we made to the
> data base. Of course after roughly 1024 connections to the database
> the application crashes with the above error as would be expected.

/dev/urandom is not used by OpenDBX directly but I think by FreeTDS if
you are using the MSSQL backend.

> Has anyone experienced this? Is there a workaround or patch? Are
> we using the library correctly?

Can you please have a look if you call Conn::unbind() and
Conn::finish() before the objects go out of scope? This is important
as the cleanup can't be done by the destructor of the class.


Norbert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS4qihAAoJEA3e3tWv2uU+7eEQAIIIZUtvrUQCTf17yn/9vyLw
cs0B8DE0kp9Dh3uUmQYWgjTlOmMofB/Z0HdQs7/1hE/LfZA3HYAQtLjmtpsWumRo
4Egxgi19KmHX+ZMowNpRlc4c/rrx3xI/VbeW0cMzRT1OdqdXUMebAsFJKyn3uCrP
pJtm7Ead00ql66Sa789tFfCpaqvZXV/9xq4ESFOP0V3BQoBF7XkyoynZ4ZWPY6lQ
0pLYn0OCSXOlWpk+9fKwKLNtQ7dY/VomR0OMM8rrVfmPaCwJI3pcMB/3HL0BBPP+
xRQHTdCQVMDPi2txp5DbKURTf0H9MkjxHGP64Pn6qqaM9294Q7trzzpz9W+FJeR+
r8D9ik0TXHVULK+cPQ5s2baN/oXT83UBTMma8rgKkj/3SlwXIz1DQccyx+NpnW4B
rXqkfXdtgdN/FKXqHLM9bMgnKyVPc9y8PKMULkYZJniia2rzNGx0MOjiTUO4Topt
nbbAeW0By+FyE6ohm3PoqEKkLpbniThAQAiV83bhVhWrIorADSq+5eF5sBzMFgTl
BkgxZPMDotJUCRYIcgSqkaK/CH94LZClWDWQDGXwnfA+OFGbfI/SeshsHTO6sx4F
DGYvDon73Ge6Q2vdvWEZDd5d21Ua4MPtkv5jFSIb0tGXjufDjNT+C5scMKadY6ZE
oVlbRhwbNu74gUw+0wxK
=UY1t
-----END PGP SIGNATURE-----

Re: [opendbx] Opendbx on github

[Guillermo P. <gui...@gm...>]

Ups, incomplete email.

https://ci.inria.fr/dbxtalk/job/OpenDBX/

If you want to follow or contribute on the CI jobs, you should create an
account in ci.inria.fr and tell me, I'll give you access.

Guille


On Thu, Oct 31, 2013 at 10:51 AM, Guillermo Polito <
gui...@gm...> wrote:

> https://github.com/guillep/OpenDBX
>
> that :)
>
> And now I'll start to setup some ci jobs.
>
> If you
>

[opendbx] Opendbx on github

[Guillermo P. <gui...@gm...>]

https://github.com/guillep/OpenDBX

that :)

And now I'll start to setup some ci jobs.

If you

Re: [opendbx] OpenDBX Continuous integration

[Guillermo P. <gui...@gm...>]

On Thu, Oct 17, 2013 at 1:27 PM, Norbert Sendetzky <no...@li...
> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Guille
>
> > I got sort of tired of compiling opendbx all the time, and test and
> > all that stuff, specially since in DBXTalk we use OpenDBX besides
> > other components. So we are starting to setup a ci server, provided
> > by Inria.
> >
> > Now, my question is, do you mind if I put OpenDBX in continuous
> > integration also? ;) Inria would support so far windows and linux
> > slaves. It's free and maintained by Inria (with its good and bad
> > things).
>
> CI is always a good thing and if you can setup the tests for OpenDBX
> this would be great.
>

great!


>
> > The other thing (maybe offtopic for this thread) I would like to do
> > to work more comfortable is to move the opendbx sources to git...
> > Yesterday I was patching Opendbx ODBC to support unicode strings
> > for example, and while I test it I would like to have my code
> > commited somewhere :). Also github for example may increase
> > visibility. However, if you think that svn is the way to go, I'm ok
> > with it.
>
> I've also already thought about this, escpecially as I'm working with
> Github in another project since last year. Up to now I didn't have the
> time to care about this yet but help is always welcome :-)
>

cool, I'll start it and keep you posted :)

Thanks!

>
>
> Norbert
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSX8l8AAoJEA3e3tWv2uU+qLMQAKXAYwYQvlY2pAdxgl5H1EZO
> JzDbFpUg+gqfI0ol/dXX6Hth+vZTdEPvOsVt3Em/lhPRmfLUJyuqvCMFyKHwJH2f
> Fe4Sea9q2qp4ZPc5qow0AC1cYeHpn4wknIEabW7DpNVfqHjdZaTNNZOJKAMDLeR8
> KG2e0pwgGZhLMtOEN+ygDJ988h7pizq/cUg1e2Mh5FKSU+qTSXQHuXPkJl2zSDDy
> 2oylKqhz1tE0qfBYFTMXzi5vA+19qpqsJj1Ga4Ru5wXsm4O1CihEo8R+CjGOMSFI
> q+MuzI02BMKrNm7ZAuskHEhIucQo8JB+lSEqVS3IydEWPvkPxdXQM3GQVT9KD2oP
> jGrFNO+eJNIgWBPV30hnMnb/5fwNVu5Hmuj+mnAM0mLVzCZLZovXjXkbfIysx1lD
> yCF7yuUsKWaAdDZWCkUUUURlxUHR5zuOCWjVBrss+I8Hqublyf1LoHh2MjentTt/
> VJrnravYvMzQB4K6opX5CB92NXJk8l5cvdwRmJgVVdpOJtszKf1OzAuNdjSmH7tD
> dszOazntMA+Xv4Z6d+seteTxaLNMHTsZ/AWa2NmPt3qhZw1UwQ0k+4hyKiVspup1
> jIdooHlje9L/pzWvGT2NIEoJuHhNnTYmI5p3QCGAWr4HL80eGAwAME6Tu5jgmoiJ
> fNLtedYTdf59DCW8hsEO
> =V58o
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> libopendbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
> http://www.linuxnetworks.de/doc/index.php/OpenDBX
>

Re: [opendbx] OpenDBX Continuous integration

[Norbert S. <no...@li...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Guille

> I got sort of tired of compiling opendbx all the time, and test and
> all that stuff, specially since in DBXTalk we use OpenDBX besides
> other components. So we are starting to setup a ci server, provided
> by Inria.
> 
> Now, my question is, do you mind if I put OpenDBX in continuous
> integration also? ;) Inria would support so far windows and linux
> slaves. It's free and maintained by Inria (with its good and bad
> things).

CI is always a good thing and if you can setup the tests for OpenDBX
this would be great.

> The other thing (maybe offtopic for this thread) I would like to do
> to work more comfortable is to move the opendbx sources to git...
> Yesterday I was patching Opendbx ODBC to support unicode strings
> for example, and while I test it I would like to have my code
> commited somewhere :). Also github for example may increase
> visibility. However, if you think that svn is the way to go, I'm ok
> with it.

I've also already thought about this, escpecially as I'm working with
Github in another project since last year. Up to now I didn't have the
time to care about this yet but help is always welcome :-)


Norbert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSX8l8AAoJEA3e3tWv2uU+qLMQAKXAYwYQvlY2pAdxgl5H1EZO
JzDbFpUg+gqfI0ol/dXX6Hth+vZTdEPvOsVt3Em/lhPRmfLUJyuqvCMFyKHwJH2f
Fe4Sea9q2qp4ZPc5qow0AC1cYeHpn4wknIEabW7DpNVfqHjdZaTNNZOJKAMDLeR8
KG2e0pwgGZhLMtOEN+ygDJ988h7pizq/cUg1e2Mh5FKSU+qTSXQHuXPkJl2zSDDy
2oylKqhz1tE0qfBYFTMXzi5vA+19qpqsJj1Ga4Ru5wXsm4O1CihEo8R+CjGOMSFI
q+MuzI02BMKrNm7ZAuskHEhIucQo8JB+lSEqVS3IydEWPvkPxdXQM3GQVT9KD2oP
jGrFNO+eJNIgWBPV30hnMnb/5fwNVu5Hmuj+mnAM0mLVzCZLZovXjXkbfIysx1lD
yCF7yuUsKWaAdDZWCkUUUURlxUHR5zuOCWjVBrss+I8Hqublyf1LoHh2MjentTt/
VJrnravYvMzQB4K6opX5CB92NXJk8l5cvdwRmJgVVdpOJtszKf1OzAuNdjSmH7tD
dszOazntMA+Xv4Z6d+seteTxaLNMHTsZ/AWa2NmPt3qhZw1UwQ0k+4hyKiVspup1
jIdooHlje9L/pzWvGT2NIEoJuHhNnTYmI5p3QCGAWr4HL80eGAwAME6Tu5jgmoiJ
fNLtedYTdf59DCW8hsEO
=V58o
-----END PGP SIGNATURE-----

[opendbx] OpenDBX Continuous integration

[Guillermo P. <gui...@gm...>]

Hi guys, Norbert,

I got sort of tired of compiling opendbx all the time, and test and all
that stuff, specially since in DBXTalk we use OpenDBX besides other
components. So we are starting to setup a ci server, provided by Inria.

Now, my question is, do you mind if I put OpenDBX in continuous integration
also? ;) Inria would support so far windows and linux slaves. It's free and
maintained by Inria (with its good and bad things).

The other thing (maybe offtopic for this thread) I would like to do to work
more comfortable is to move the opendbx sources to git... Yesterday I was
patching Opendbx ODBC to support unicode strings for example, and while I
test it I would like to have my code commited somewhere :). Also github for
example may increase visibility. However, if you think that svn is the way
to go, I'm ok with it.

Thanks!
Guille

Re: [opendbx] Error handling

[Waters, B. <bw...@sa...>]

Norbert,

Thanks for the response.  I am current using freetds 0.82.  I started
with version 0.91, but encountered a seg fault, so I went back to 0.82.
In digging through freetds, it appears to be a design oversight.  In
this case, the error handler is being called from
_dblib_handle_info_message().  This method does not capture the return
value from the error handler, therefore it does not cancel the
operation.  Maybe they are expecting to handle the processing of info
messages through some other mechanism other than an error handler.

In any case, I have posted a question to the freetds mail list.

Thanks, Brian.

-----Original Message-----
From: Norbert Sendetzky [mailto:no...@li...] 
Sent: Friday, October 04, 2013 12:08 PM
To: OpenDBX devel list
Subject: Re: [opendbx] Error handling

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brian

> Thanks for the quick response.  Below is the SQL statement that is 
> getting executed and below that is code.  It appears that the
> issue might revolve around the dbsqlok().  When dbsqlok() is called
> in mssql_odbx_result() the following sequence occurs 1)
> mssql_msg_handler() is called with the primary key violation
> message, 2) mssql_err_handler() is called, and 3)
> mssql_msg_handler() is called indicating that the statement has
> been terminated.  Then dbsqlok() returns with a return value other
> than FAIL.  Since dbsqlok() does not return FAIL, -ODBX_ERR_BACKEND
> is not returned and an exception is not raised.

Thanks for debugging the problem.
I think it's OK that dbsqlok() does not return "FAIL" because the SQL
statement is correct. Only the execution fails due to the primary key
constraint so I would expect that dbresults() should return something
else than "SUCCEED" or "NO_MORE_RESULTS".

The mssql_err_handler function returns "INT_CANCEL" in your case which
should case a "FAIL" in the function that encountered the error.

Do you use FreeTDS? Which version?
I had a look into the latest version (0.92.79) but I'm not sure how
this problem is handled there. The documentation of the functions
doesn't help either:

dbsqlok():
Wait for results of a query from the server. \retval FAIL SQL syntax
error, typically.

dbresult():
Call dbresults() after calling dbsqlexec() or dbsqlok(), or
dbrpcsend() returns SUCCEED. Unless one of them fails, dbresults will
return either SUCCEED or NO_MORE_RESULTS. SUCCEED does not imply that
DBROWS() will return TRUE or even that dbnumcols() will return nonzero.

dbperror():
Call client-installed error handler. the handler's return code,
subject to correction and adjustment for vendor style: - INT_CANCEL
The db-lib function that encountered the error will return FAIL.

So according to the documentation it should work this way :-/
Maybe you should ask on the FreeTDS list too if this is a bug in the
FreeTDS library.


Norbert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSTvXeAAoJEA3e3tWv2uU+69kQAKZyo0FuoznPHgCEM8LIOpk3
tHitmXLbE3ywGv9JdNraKEERfqQx+9gfoViIbjygD6G2bOJKgyZ+lZXWyZDZojCD
nGq5p8HE6LMdyB9dmnewjjVHp675mzfliD7W4zK/JHtq9JjPWGEaybIEwgNUrz+n
sqnKObwjyzuA47nxT9WsmT2Et9t/awv07Vn91kN8NLQtHqye02Cfbhs+piE9/5zy
90+lKGgNl6htyVGhqVSvI5vHGbxOD84eE36Iux8VAMNc/AYU1PvZlP+wcNGr60zR
U9kop0iRS8ZEvdQ9Q9NQeRQtQm0ekLGeceBzGOXBPESfxwiG6OQrD1bCfBswHEwp
269gSYi+6gzo33+YtUdeVZf8wFPwoRzKvE3w4QQ35HPtXjmxKNaLL879+1O026dj
fHvqnoTHuWHGCpPanx5Fbt3LWd92rExDzBSybWUjXxkwhIQL67JWpft8crcPUOcR
YIkYoDPamGSGwfGCINetnh5ttTzjxa1X/FYfNtcy/FLEUUN61TmqVwoCdElLzVUz
AXDCwXXohdVJjdGobDOF5j0tuk3IkiBIwzyDVBUafZDSEOf0l5dLKzd0TaDP3z5H
yiIbk0AkvvLseHAQCQKCJJWLA9BOab/LandE7Rq8WtnrdC/JeCD55kFKJug1a2A/
bndImUrR0qtxR28hwTty
=YTTi
-----END PGP SIGNATURE-----

------------------------------------------------------------------------
------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from 
the latest Intel processors and coprocessors. See abstracts and register
>
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clk
trk
_______________________________________________
libopendbx-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
http://www.linuxnetworks.de/doc/index.php/OpenDBX

Re: [opendbx] Error handling

[Norbert S. <no...@li...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brian

> Thanks for the quick response.  Below is the SQL statement that is 
> getting executed and below that is code.  It appears that the
> issue might revolve around the dbsqlok().  When dbsqlok() is called
> in mssql_odbx_result() the following sequence occurs 1)
> mssql_msg_handler() is called with the primary key violation
> message, 2) mssql_err_handler() is called, and 3)
> mssql_msg_handler() is called indicating that the statement has
> been terminated.  Then dbsqlok() returns with a return value other
> than FAIL.  Since dbsqlok() does not return FAIL, -ODBX_ERR_BACKEND
> is not returned and an exception is not raised.

Thanks for debugging the problem.
I think it's OK that dbsqlok() does not return "FAIL" because the SQL
statement is correct. Only the execution fails due to the primary key
constraint so I would expect that dbresults() should return something
else than "SUCCEED" or "NO_MORE_RESULTS".

The mssql_err_handler function returns "INT_CANCEL" in your case which
should case a "FAIL" in the function that encountered the error.

Do you use FreeTDS? Which version?
I had a look into the latest version (0.92.79) but I'm not sure how
this problem is handled there. The documentation of the functions
doesn't help either:

dbsqlok():
Wait for results of a query from the server. \retval FAIL SQL syntax
error, typically.

dbresult():
Call dbresults() after calling dbsqlexec() or dbsqlok(), or
dbrpcsend() returns SUCCEED. Unless one of them fails, dbresults will
return either SUCCEED or NO_MORE_RESULTS. SUCCEED does not imply that
DBROWS() will return TRUE or even that dbnumcols() will return nonzero.

dbperror():
Call client-installed error handler. the handler's return code,
subject to correction and adjustment for vendor style: - INT_CANCEL
The db-lib function that encountered the error will return FAIL.

So according to the documentation it should work this way :-/
Maybe you should ask on the FreeTDS list too if this is a bug in the
FreeTDS library.


Norbert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSTvXeAAoJEA3e3tWv2uU+69kQAKZyo0FuoznPHgCEM8LIOpk3
tHitmXLbE3ywGv9JdNraKEERfqQx+9gfoViIbjygD6G2bOJKgyZ+lZXWyZDZojCD
nGq5p8HE6LMdyB9dmnewjjVHp675mzfliD7W4zK/JHtq9JjPWGEaybIEwgNUrz+n
sqnKObwjyzuA47nxT9WsmT2Et9t/awv07Vn91kN8NLQtHqye02Cfbhs+piE9/5zy
90+lKGgNl6htyVGhqVSvI5vHGbxOD84eE36Iux8VAMNc/AYU1PvZlP+wcNGr60zR
U9kop0iRS8ZEvdQ9Q9NQeRQtQm0ekLGeceBzGOXBPESfxwiG6OQrD1bCfBswHEwp
269gSYi+6gzo33+YtUdeVZf8wFPwoRzKvE3w4QQ35HPtXjmxKNaLL879+1O026dj
fHvqnoTHuWHGCpPanx5Fbt3LWd92rExDzBSybWUjXxkwhIQL67JWpft8crcPUOcR
YIkYoDPamGSGwfGCINetnh5ttTzjxa1X/FYfNtcy/FLEUUN61TmqVwoCdElLzVUz
AXDCwXXohdVJjdGobDOF5j0tuk3IkiBIwzyDVBUafZDSEOf0l5dLKzd0TaDP3z5H
yiIbk0AkvvLseHAQCQKCJJWLA9BOab/LandE7Rq8WtnrdC/JeCD55kFKJug1a2A/
bndImUrR0qtxR28hwTty
=YTTi
-----END PGP SIGNATURE-----