On 03/17/2012 10:00 PM, Paul Harris wrote:
>
>
> On 16 March 2012 08:42, Simon Walter <[email protected]
> <mailto:[email protected]>> wrote:
>
>     On 03/15/2012 03:07 PM, Simon Walter wrote:
>      > Hi all,
>      >
>      > I'm trying read some data from an SQL Server database via ODBC
>     ala SOCI.
>      > Everything seems to work except for varchar columns. SQLDescribeCol
>      > generates an error and odbc_soci_error
>      > "column size" is thrown (soci/src/backends/odbc/statement.cpp -
>      > odbc_statement_backend::column_size())
>      >
>      > I've tried different DBs on the same server, and I still get the same
>      > problem.
>      >
>      > The code is as simple as it gets:
>      >
>      > std::string resName;
>      > int res = 5;
>      > session mssql(odbc, connectString);
>      > mssql<< "select name from test.dbo.res where id = :res", use(res,
>      > "res"), into(resName);
>      >
>
>     A follow up to this:
>
>     I've tried the using row.get<string>(0) with the same results:
>
>     /usr/local/include/soci/row.h:68: T soci::row::get(size_t) const [with T
>     = std::basic_string<char, std::char_traits<char>, std::allocator<char>
>      >]: Assertion `holders_.size() >= pos + 1' failed.
>
>     and a odbc_soci_error with "column size".
>
>     I've tried the same queries with libodbc++ and get back results
>     correctly.
>
>     I don't see how something as common as that would be a bug, but perhaps
>     no one is using odbc. I'm using unixODBC 2.2.14.
>
>     How can I verify this is (not) a bug with unixODBC?
>
>     Thanks,
>
>     Simon
>
>
> Does this look related?
>
> https://issues.asterisk.org/jira/browse/ASTERISK-16946
>
> I have stumbled onto unixodbc bugs before, the one I hit still exists in
> the current Debian unixodbc, although its fixed in the latest unixodbc
> source release.
>
> Are you running a 64-bit machine?
> Does the bug occur on a 32-bit machine?
>

Thanks Paul,

It looks like it could be related. However, I am using a 32-bit OS 
(debian 6) VM hosted on a 64bit machine. So I don't think any 64bit 
issues are a problem here. Though, it does look like it could be a 
unixODBC issue. Is there any way I could verify it is indeed unixODBC 
before I go through with building everything?

Simon

-- 
simonsmicrophone.com

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users

Reply via email to