psqlodbc: No memory available to store statement
| От | AYahorau@ibagroup.eu |
|---|---|
| Тема | psqlodbc: No memory available to store statement |
| Дата | |
| Msg-id | OFC9545664.2FA8A868-ON43258424.003D84C0-43258424.0044921C@iba.by обсуждение исходный текст |
| Ответы |
Re: psqlodbc: No memory available to store statement
|
| Список | pgsql-odbc |
Hello PostgreSQL Community!
I widely use psqlodb driver with unixODBC manager on my SLES12 linux machine.
Not very long ago I updated psqlodbc driver from 10.03.0000 to the latest one 11.01.0000 .
I use unixODBC-2.3.6-7.9.1.x86_64 package installed from YAST setup and configurational tool and configure, build, and install psqlodbc from the source code in the same way as for psqlodbc 10.03.0000:
autoreconf -i
./configure --prefix=path_to_install --with-libpq=path_to_pg_config --with-unixodbc=path_to_odbc_config
make
make install
In my program I use quite common ODBC functions to establish a connection, perform a query, retrieve a result:
SQLConnect, SQLExecDirect, SQLFetch etc.
But after I had installed psqlodbc11.01.0000 I am constantly getting the following error:
No memory available to store statement *** PostgreSQL SQLSTATE = HY001
I inspected all the changes in 11.00.0000 and 11.01.0000 versions and found out that this behaviour is caused by the following commit:
1086a6 2018-05-23 | Call AC_CHECK_SIZEOF(long int) in configure.ac and always place config.h before sql....h. Due to this change, sqltypes.h of unixODBC can recognize SIZEOF_LONG_INT used in psqlodbc driver. [Hiroshi Inoue]
So, in this case I see that configure script generates config.h file with defined SIZEOF_LONG_INT: #define SIZEOF_LONG_INT 0,
while odcb_config --header says:
#define SIZEOF_LONG_INT 8
So, in regard to this situation I have some questions.
Unfortunately there is not enough information. So what was the aim of this commit? 1086a6 2018-05-23 | Call AC_CHECK_SIZEOF(long int) in configure.ac and always place config.h before sql....h. Due to this change, sqltypes.h of unixODBC can recognize SIZEOF_LONG_INT used in psqlodbc driver. [Hiroshi Inoue]
Did anybody face this issue? (No memory available to store statement *** PostgreSQL SQLSTATE = HY001 )
What do I do wrong? How to resolve this issue?
Best regards,
Andrei Yahorau
I widely use psqlodb driver with unixODBC manager on my SLES12 linux machine.
Not very long ago I updated psqlodbc driver from 10.03.0000 to the latest one 11.01.0000 .
I use unixODBC-2.3.6-7.9.1.x86_64 package installed from YAST setup and configurational tool and configure, build, and install psqlodbc from the source code in the same way as for psqlodbc 10.03.0000:
autoreconf -i
./configure --prefix=path_to_install --with-libpq=path_to_pg_config --with-unixodbc=path_to_odbc_config
make
make install
In my program I use quite common ODBC functions to establish a connection, perform a query, retrieve a result:
SQLConnect, SQLExecDirect, SQLFetch etc.
But after I had installed psqlodbc11.01.0000 I am constantly getting the following error:
No memory available to store statement *** PostgreSQL SQLSTATE = HY001
I inspected all the changes in 11.00.0000 and 11.01.0000 versions and found out that this behaviour is caused by the following commit:
1086a6 2018-05-23 | Call AC_CHECK_SIZEOF(long int) in configure.ac and always place config.h before sql....h. Due to this change, sqltypes.h of unixODBC can recognize SIZEOF_LONG_INT used in psqlodbc driver. [Hiroshi Inoue]
So, in this case I see that configure script generates config.h file with defined SIZEOF_LONG_INT: #define SIZEOF_LONG_INT 0,
while odcb_config --header says:
#define SIZEOF_LONG_INT 8
So, in regard to this situation I have some questions.
Unfortunately there is not enough information. So what was the aim of this commit? 1086a6 2018-05-23 | Call AC_CHECK_SIZEOF(long int) in configure.ac and always place config.h before sql....h. Due to this change, sqltypes.h of unixODBC can recognize SIZEOF_LONG_INT used in psqlodbc driver. [Hiroshi Inoue]
Did anybody face this issue? (No memory available to store statement *** PostgreSQL SQLSTATE = HY001 )
What do I do wrong? How to resolve this issue?
Best regards,
Andrei Yahorau
В списке pgsql-odbc по дате отправления: