Discussion:
[freetds] Fwd: [unixODBC-support] PHP PDO unixODBC FreeTDS SQL Server text column size
Jochen Daum
2012-09-24 01:28:31 UTC
Permalink
Hi,

I am investigating an issue whereby an empty column is returned for a
text field when using PHP PDO unixODBC FreeTDS SQL Server.

I'm running Ubuntu 12.04 and my FreeTDS file is as here

/etc/freetds/freetds.ini

# Global settings are overridden by those in a database
# server specific section
[global]
# TDS protocol version

# Whether to write a TDSDUMP file for diagnostic purposes
# (setting this to /tmp is insecure on a multi-user system)
dump file = /tmp/freetds.log
dump file append
debug flags = 0xffff

# Command and connection timeouts
; timeout = 10
; connect timeout = 10

# If you get out-of-memory errors, it may mean that your client
# is trying to allocate a huge buffer for a TEXT field.
# Try setting 'text size' to a more reasonable limit
client charset = UTF-8
tds version = 8.0
text size = 10971520
port = 1433


As per below from the unixODBC mailing list, it appears my restriction
is at the driver (=freetds) level.

I also found this:
http://yahowto.blogspot.co.nz/2011/01/fix-ntext-problems-with-php-freetds.html,
but changing the column from text to varchar(max) did not help.

Any idea how to diagnose this. I also seem to have no FreeTDS logging.

Thanks for any help,

Jochen


---------- Forwarded message ----------
From: Nick Gorham <nick at lurcher.org>
Date: 24 September 2012 11:10
Subject: Re: [unixODBC-support] PHP PDO unixODBC FreeTDS SQL Server
text column size
To: Support for the unixODBC project <unixodbc-support at mailman.unixodbc.org>
Hi again,
with odbc Trace enabled I see now that the size of the text column
that doesn't work is restricted to 4096 bytes, at least this is how I
Column Name = [attaContent]
Data Type = 0x7fbf7136d618 -> -1
Column Size = 0x7fff8c0d11d4 -> 4096
Decimal Digits = NULLPTR
Nullable = NULLPTR
[ODBC][29384][1348216767.780752][SQLColAttribute.c][286]
Statement = 0x7fbf712a2580
Column Number = 6
Field Identifier = SQL_DESC_DISPLAY_SIZE
Character Attr = (nil)
Buffer Length = 0
String Length = (nil)
Numeric Attribute = 0x7fff8c0d11d8
[ODBC][29384][1348216767.780768][SQLColAttribute.c][657]
Exit:[SQL_SUCCESS]
Well, the driver is reporting that the column is 4096 bytes long, and
is a SQL_LONGVARCHAR.
Is there a setting to control the maximum number of bytes returned. I
odbc.defaultlrl = 10000000
(also have
mssql.textlimit = 2147483647
; Valid range 0 - 2147483647. Default = 4096.
mssql.textsize = 2147483647
but this shouldn't matter, correct?)
No, the driver is reporting the column size, setting PHP variables
wont change the driver.

--
Nick
_______________________________________________
unixODBC-support mailing list
unixODBC-support at mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
--
P.S.: Latest newsletter: Website application reporting - an overview -
http://eepurl.com/pKrAD

Kind Regards,

Jochen Daum

"There is no shortcut to anywhere worth going" - Beverly Sills

Automatem Ltd
Phone: +64 9 630 3425
Mobile: +64 21 567 853
Email: jd at automatem.co.nz
Website: www.automatem.co.nz
Skype: jochendaum
http://nz.linkedin.com/in/automatem
http://twitter.com/automatem
James K. Lowden
2012-09-24 14:21:35 UTC
Permalink
On Mon, 24 Sep 2012 13:28:31 +1200
Post by Jochen Daum
I am investigating an issue whereby an empty column is returned for a
text field when using PHP PDO unixODBC FreeTDS SQL Server.
To determine if the FreeTDS ODBC driver is able to process your query
results, I recommend testing it with bsqlodbc. If that works, you can
have some confidence that the driver works as expected. That is, as
the authors intended.

To get better information in situ, TDSDUMP is your friend.
Post by Jochen Daum
I also seem to have no FreeTDS logging.
I assume you've read the UG on the question. Make sure TDSDUMP is set
before you start the process that uses ODBC. FreeTDS will honor
TDSDUMP, definitely.

HTH.

--jkl
Jochen Daum
2012-09-25 00:59:48 UTC
Permalink
Ok,
Post by James K. Lowden
Post by Jochen Daum
I am investigating an issue whereby an empty column is returned for a
text field when using PHP PDO unixODBC FreeTDS SQL Server.
To determine if the FreeTDS ODBC driver is able to process your query
results, I recommend testing it with bsqlodbc. If that works, you can
have some confidence that the driver works as expected. That is, as
the authors intended.
When I run this query through bsqlodbc

select [Attachment].[attaContent] from [Attachment] where
([Attachment].[attaId] = 10239)

I get bsqlodbc: error -2: SQLAllocHandle: invalid handle: failed
Post by James K. Lowden
To get better information in situ, TDSDUMP is your friend.
Post by Jochen Daum
I also seem to have no FreeTDS logging.
I assume you've read the UG on the question. Make sure TDSDUMP is set
before you start the process that uses ODBC. FreeTDS will honor
TDSDUMP, definitely.
TDSDUMP shows this at the end of the log for the query above

token.c:555:processing result tokens. marker is 81(TDS7_RESULT)
token.c:1515:processing TDS7 result metadata.
mem.c:615:tds_free_all_results()
token.c:1540:set current_results (1 column) to tds->res_info
token.c:1547:setting up 1 columns
token.c:1486:tds7_get_data_info:
colname = attaContent (11 bytes)
type = 35 (text)
server's type = 35 (text)
column_varint_size = 4
column_size = 2147483647 (2147483647 on server)
token.c:1556: name size/wsize type/wtype utype
token.c:1557: -------------------- --------------- --------------- -------
token.c:1567: attaContent 2147483647/2147483647 35/35 0
util.c:156:Changed query state from READING to PENDING
odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 1
odbc.c:3535: result_type=4049, TDS_DONE_COUNT=0, TDS_DONE_ERROR=2
odbc.c:3605:odbc_process_tokens: returning result_type 4049
odbc.c:3374:_SQLExecute: odbc_process_tokens returned result_type 4049
token.c:540:tds_process_tokens(0x8027e0, 0x7fff9589f4e8, 0x7fff9589f4ec, 0x6914)
util.c:156:Changed query state from PENDING to READING
token.c:555:processing result tokens. marker is d1(ROW)
token.c:666:tds_process_tokens::SET_RETURN stopping on current token
util.c:156:Changed query state from READING to PENDING
odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 1
odbc.c:3535: result_type=4040, TDS_DONE_COUNT=0, TDS_DONE_ERROR=2
odbc.c:3605:odbc_process_tokens: returning result_type 4040


Any idea where to take it from here?

Kind Regards,

Jochen
James K. Lowden
2012-09-25 03:05:00 UTC
Permalink
On Tue, 25 Sep 2012 12:59:48 +1200
Post by Jochen Daum
Post by James K. Lowden
To determine if the FreeTDS ODBC driver is able to process your
query results, I recommend testing it with bsqlodbc. If that
works, you can have some confidence that the driver works as
expected. That is, as the authors intended.
When I run this query through bsqlodbc
select [Attachment].[attaContent] from [Attachment] where
([Attachment].[attaId] = 10239)
I get bsqlodbc: error -2: SQLAllocHandle: invalid handle: failed
Well, we can file that under "doesn't work". Did you get no other
message before that one? Usually a TDS_DONE_ERROR from the server is
preceded by a message, and something like "invalid handle" would occur
later, after the program continues blithely on. That's "usually" as
in, I've never seen an exception.
Post by Jochen Daum
column_size = 2147483647 (2147483647 on server)
Does it help if you "set textsize 10000000" (10 million) first? The
constraint in your configuration file
Post by Jochen Daum
text size = 10971520
might not matter; you said its name is "/etc/freetds/freetds.ini" and
that would normally be /etc/freetds/freetds.conf.

--jkl
Jochen Daum
2012-09-25 21:31:08 UTC
Permalink
Post by James K. Lowden
Post by Jochen Daum
Post by James K. Lowden
To determine if the FreeTDS ODBC driver is able to process your
query results, I recommend testing it with bsqlodbc. If that
works, you can have some confidence that the driver works as
expected. That is, as the authors intended.
When I run this query through bsqlodbc
select [Attachment].[attaContent] from [Attachment] where
([Attachment].[attaId] = 10239)
I get bsqlodbc: error -2: SQLAllocHandle: invalid handle: failed
Well, we can file that under "doesn't work". Did you get no other
message before that one? Usually a TDS_DONE_ERROR from the server is
preceded by a message, and something like "invalid handle" would occur
later, after the program continues blithely on. That's "usually" as
in, I've never seen an exception.
Post by Jochen Daum
column_size = 2147483647 (2147483647 on server)
Does it help if you "set textsize 10000000" (10 million) first? The
constraint in your configuration file
I can't see any other error message, but admittedly this is the first
time I log at freetds logs. I've modified my query to:

set textsize 10000000
select attaRefTable from [Attachment] where ([Attachment].[attaId] = 10239)

- I tried "go" inbetween the 2 statements and it threw an error
- attaRefTable is a varchar(30)
Post by James K. Lowden
Post by Jochen Daum
text size = 10971520
might not matter; you said its name is "/etc/freetds/freetds.ini" and
that would normally be /etc/freetds/freetds.conf.
That was a mixup by myself. its /etc/freetds/freetds.conf

I also found that I used tds version = 8.0, which doesn't exist, so I
changed this to 7.2.

In summary:

bsqlodbc -v -Uwebsite -Ppassword -SEIS -DExportInformationSystem -o
output -e error -i Attachment.sql

returns

output: empty
error:
bsqlodbc:273: Verbose operation enabled
bsqlodbc:366: Query:
set textsize 10000000
select attaRefTable from [Attachment] where ([Attachment].[attaId] = 10239)
Metadata
col name type value type name
size varies
------ ------------------------------ ---------- ------------------
------ ------
bsqlodbc: error -2: SQLAllocHandle: invalid handle: failed

freetds.log attached.

Thanks for any further pointers.
Post by James K. Lowden
--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
--
P.S.: Latest newsletter: Website application reporting - an overview -
http://eepurl.com/pKrAD

Kind Regards,

Jochen Daum

"There is no shortcut to anywhere worth going" - Beverly Sills

Automatem Ltd
Phone: +64 9 630 3425
Mobile: +64 21 567 853
Email: jd at automatem.co.nz
Website: www.automatem.co.nz
Skype: jochendaum
http://nz.linkedin.com/in/automatem
http://twitter.com/automatem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freetds.log
Type: application/octet-stream
Size: 28887 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/freetds/attachments/20120926/3aa6557b/attachment-0001.obj
James K. Lowden
2012-09-27 03:36:09 UTC
Permalink
On Wed, 26 Sep 2012 09:31:08 +1200
Post by Jochen Daum
bsqlodbc -v -Uwebsite -Ppassword -SEIS -DExportInformationSystem -o
output -e error -i Attachment.sql
returns
output: empty
bsqlodbc:273: Verbose operation enabled
set textsize 10000000
select attaRefTable from [Attachment] where ([Attachment].
[attaId] = 10239) Metadata
col name type value type name
size varies
------ ------------------------------ ---------- ------------------
------ ------
bsqlodbc: error -2: SQLAllocHandle: invalid handle: failed
freetds.log attached.
Thanks, that's enough that I've run out of questions. Unfortunately,
I'm fresh out of answers, too. :-(

The error is either in bsqlodbc or in the driver. If unixODBC's isql
can process the query, it's a bug either in bsqlodbc. Otherwise
there's a problem with SQLDescribeCol. Let's see what we know:

1. bsqlodbc -v tried to print the metadata. To do that it called
SQLDescribeCol(). That's the last line of your TDSDUMP. It failed:
bsqlodbc was unable to print any metadata, even though the metadata had
arrived from the server,
Post by Jochen Daum
colname = attaRefTable (12 bytes)
type = 39 (varchar)
server's type = 167 (xvarchar)
column_varint_size = 2
column_size = 30 (30 on server)
(That doesn't look like the same column as in your last message
which was "attaContent", type text.)

2. The problem went undetected by bsqlodbc, which means SQLDescribeCol
didn't return an error. If it had, bsqlodbc would have noticed, and
exited immediately, on line 544. Perhaps bad inputs were passed to
SQLDescribeCol. If so, it failed to report that fact.

3. bsqlodbc continued on to SQLAllocHandle(), which rejected the
hstmt parameter. At that point bsqlodbc quit. This is not captured in
the log because in odbc.c, _SQLAllocDesc() tests the hdbc parameter
before logging the call.

This looks broken to me: SQLAllocHandle() is passed SQLHSTMT, a
statement handle, but passes it to _SQLAllocDesc(), which tests its
validity as SQLHDBC, a connection handle, with ODBC_ENTER_HDBC.
Perhaps Frediano can shed some light here. I think parameter should be
a statement handle and the test should be ODBC_ENTER_HSTMT. But this
code is undoubtedly called frequently and surely works?

In sum,

There seem to be problems in error-checking in SQLDescribeCol and maybe
_SQLAllocDesc. There might be a bug in bsqlodbc triggering all that.

If there is a problem in the driver, it might explain what you're
seeing in PHP.

HTH.

--jkl
Jochen Daum
2012-09-27 03:55:06 UTC
Permalink
Thanks,
Post by James K. Lowden
Post by Jochen Daum
bsqlodbc -v -Uwebsite -Ppassword -SEIS -DExportInformationSystem -o
output -e error -i Attachment.sql
returns
output: empty
bsqlodbc:273: Verbose operation enabled
set textsize 10000000
select attaRefTable from [Attachment] where ([Attachment].
[attaId] = 10239) Metadata
col name type value type name
size varies
------ ------------------------------ ---------- ------------------
------ ------
bsqlodbc: error -2: SQLAllocHandle: invalid handle: failed
freetds.log attached.
Thanks, that's enough that I've run out of questions. Unfortunately,
I'm fresh out of answers, too. :-(
The error is either in bsqlodbc or in the driver. If unixODBC's isql
can process the query, it's a bug either in bsqlodbc. Otherwise
1. bsqlodbc -v tried to print the metadata. To do that it called
bsqlodbc was unable to print any metadata, even though the metadata had
arrived from the server,
Post by Jochen Daum
colname = attaRefTable (12 bytes)
type = 39 (varchar)
server's type = 167 (xvarchar)
column_varint_size = 2
column_size = 30 (30 on server)
(That doesn't look like the same column as in your last message
which was "attaContent", type text.)
No, I've changed it to a varchar column, which doesn't work either.
int columns work.
Post by James K. Lowden
2. The problem went undetected by bsqlodbc, which means SQLDescribeCol
didn't return an error. If it had, bsqlodbc would have noticed, and
exited immediately, on line 544. Perhaps bad inputs were passed to
SQLDescribeCol. If so, it failed to report that fact.
3. bsqlodbc continued on to SQLAllocHandle(), which rejected the
hstmt parameter. At that point bsqlodbc quit. This is not captured in
the log because in odbc.c, _SQLAllocDesc() tests the hdbc parameter
before logging the call.
This looks broken to me: SQLAllocHandle() is passed SQLHSTMT, a
statement handle, but passes it to _SQLAllocDesc(), which tests its
validity as SQLHDBC, a connection handle, with ODBC_ENTER_HDBC.
Perhaps Frediano can shed some light here. I think parameter should be
a statement handle and the test should be ODBC_ENTER_HSTMT. But this
code is undoubtedly called frequently and surely works?
In sum,
There seem to be problems in error-checking in SQLDescribeCol and maybe
_SQLAllocDesc. There might be a bug in bsqlodbc triggering all that.
If there is a problem in the driver, it might explain what you're
seeing in PHP.
I've used Ubuntu 12.04 packages, shall I compile freetds from source maybe?

Kind Regards,

Jochen
Frediano Ziglio
2012-09-28 07:00:33 UTC
Permalink
Post by James K. Lowden
On Wed, 26 Sep 2012 09:31:08 +1200
Post by Jochen Daum
bsqlodbc -v -Uwebsite -Ppassword -SEIS -DExportInformationSystem -o
output -e error -i Attachment.sql
returns
output: empty
bsqlodbc:273: Verbose operation enabled
set textsize 10000000
select attaRefTable from [Attachment] where ([Attachment].
[attaId] = 10239) Metadata
col name type value type name
size varies
------ ------------------------------ ---------- ------------------
------ ------
bsqlodbc: error -2: SQLAllocHandle: invalid handle: failed
freetds.log attached.
Thanks, that's enough that I've run out of questions. Unfortunately,
I'm fresh out of answers, too. :-(
The error is either in bsqlodbc or in the driver. If unixODBC's isql
can process the query, it's a bug either in bsqlodbc. Otherwise
1. bsqlodbc -v tried to print the metadata. To do that it called
bsqlodbc was unable to print any metadata, even though the metadata had
arrived from the server,
Post by Jochen Daum
colname = attaRefTable (12 bytes)
type = 39 (varchar)
server's type = 167 (xvarchar)
column_varint_size = 2
column_size = 30 (30 on server)
(That doesn't look like the same column as in your last message
which was "attaContent", type text.)
2. The problem went undetected by bsqlodbc, which means SQLDescribeCol
didn't return an error. If it had, bsqlodbc would have noticed, and
exited immediately, on line 544. Perhaps bad inputs were passed to
SQLDescribeCol. If so, it failed to report that fact.
3. bsqlodbc continued on to SQLAllocHandle(), which rejected the
hstmt parameter. At that point bsqlodbc quit. This is not captured in
the log because in odbc.c, _SQLAllocDesc() tests the hdbc parameter
before logging the call.
This looks broken to me: SQLAllocHandle() is passed SQLHSTMT, a
statement handle, but passes it to _SQLAllocDesc(), which tests its
validity as SQLHDBC, a connection handle, with ODBC_ENTER_HDBC.
Perhaps Frediano can shed some light here. I think parameter should be
a statement handle and the test should be ODBC_ENTER_HSTMT. But this
code is undoubtedly called frequently and surely works?
In sum,
There seem to be problems in error-checking in SQLDescribeCol and maybe
_SQLAllocDesc. There might be a bug in bsqlodbc triggering all that.
If there is a problem in the driver, it might explain what you're
seeing in PHP.
HTH.
I wrongly pushed a patch that fix some issue with characters and
bsqlodbc in Branch-0.91.

Wrongly just cause was not correctly tested, I reverted some changes.

Mainly:
- if you want just to get information from row you should get row
implementation descriptor, not create a new one as the new one would
have empty information
- SQLAllocHandle for descriptor wants a connection, not a statement,
this is the reason for the invalid handle returned
- SQLFetch can return SQL_NO_TOTAL (usually -4) if can't translate all
string to the check data[c].len > 0 can be false, I increased buffer
allocated for string however if string is empty the assert will still
raise. It would be better to handle correctly SQL_NO_TOTAL.

Frediano
James K. Lowden
2012-09-29 05:01:15 UTC
Permalink
On Fri, 28 Sep 2012 08:00:33 +0100
Post by Frediano Ziglio
Post by James K. Lowden
There seem to be problems in error-checking in SQLDescribeCol and
maybe _SQLAllocDesc. There might be a bug in bsqlodbc triggering
all that.
...
Post by Frediano Ziglio
I wrongly pushed a patch that fix some issue with characters and
bsqlodbc in Branch-0.91.
Wrongly just cause was not correctly tested, I reverted some changes.
...
Post by Frediano Ziglio
- SQLAllocHandle for descriptor wants a connection, not a statement,
this is the reason for the invalid handle returned
Is bsqlodbc in the current patched 0.91 release expected to work in
this scenario?

--jkl
Frediano Ziglio
2012-09-29 08:58:19 UTC
Permalink
Post by James K. Lowden
On Fri, 28 Sep 2012 08:00:33 +0100
Post by Frediano Ziglio
Post by James K. Lowden
There seem to be problems in error-checking in SQLDescribeCol and
maybe _SQLAllocDesc. There might be a bug in bsqlodbc triggering
all that.
...
Post by Frediano Ziglio
I wrongly pushed a patch that fix some issue with characters and
bsqlodbc in Branch-0.91.
Wrongly just cause was not correctly tested, I reverted some changes.
...
Post by Frediano Ziglio
- SQLAllocHandle for descriptor wants a connection, not a statement,
this is the reason for the invalid handle returned
Is bsqlodbc in the current patched 0.91 release expected to work in
this scenario?
Yes, now should print characters.

Frediano
Jochen Daum
2012-09-29 10:59:12 UTC
Permalink
Sorry,

am I supposed to use the HEAD of 0.91 branch or the nightly snapshot?

Kind Regards,

Jochen
Post by Frediano Ziglio
Post by James K. Lowden
On Fri, 28 Sep 2012 08:00:33 +0100
Post by Frediano Ziglio
Post by James K. Lowden
There seem to be problems in error-checking in SQLDescribeCol and
maybe _SQLAllocDesc. There might be a bug in bsqlodbc triggering
all that.
...
Post by Frediano Ziglio
I wrongly pushed a patch that fix some issue with characters and
bsqlodbc in Branch-0.91.
Wrongly just cause was not correctly tested, I reverted some changes.
...
Post by Frediano Ziglio
- SQLAllocHandle for descriptor wants a connection, not a statement,
this is the reason for the invalid handle returned
Is bsqlodbc in the current patched 0.91 release expected to work in
this scenario?
Yes, now should print characters.
Frediano
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
--
P.S.: Latest newsletter: Website application reporting - an overview -
http://eepurl.com/pKrAD

Kind Regards,

Jochen Daum

"There is no shortcut to anywhere worth going" - Beverly Sills

Automatem Ltd
Phone: +64 9 630 3425
Mobile: +64 21 567 853
Email: jd at automatem.co.nz
Website: www.automatem.co.nz
Skype: jochendaum
http://nz.linkedin.com/in/automatem
http://twitter.com/automatem
Frediano Ziglio
2012-09-29 13:36:54 UTC
Permalink
Post by Jochen Daum
Sorry,
am I supposed to use the HEAD of 0.91 branch or the nightly snapshot?
Kind Regards,
Jochen
Take the git HEAD.

James, it seems that the daily snapshot are not produced since a
month, check your cron and logs.

Frediano
Post by Jochen Daum
Post by Frediano Ziglio
Post by James K. Lowden
On Fri, 28 Sep 2012 08:00:33 +0100
Post by Frediano Ziglio
Post by James K. Lowden
There seem to be problems in error-checking in SQLDescribeCol and
maybe _SQLAllocDesc. There might be a bug in bsqlodbc triggering
all that.
...
Post by Frediano Ziglio
I wrongly pushed a patch that fix some issue with characters and
bsqlodbc in Branch-0.91.
Wrongly just cause was not correctly tested, I reverted some changes.
...
Post by Frediano Ziglio
- SQLAllocHandle for descriptor wants a connection, not a statement,
this is the reason for the invalid handle returned
Is bsqlodbc in the current patched 0.91 release expected to work in
this scenario?
Yes, now should print characters.
Frediano
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
--
P.S.: Latest newsletter: Website application reporting - an overview -
http://eepurl.com/pKrAD
Kind Regards,
Jochen Daum
"There is no shortcut to anywhere worth going" - Beverly Sills
Automatem Ltd
Phone: +64 9 630 3425
Mobile: +64 21 567 853
Email: jd at automatem.co.nz
Website: www.automatem.co.nz
Skype: jochendaum
http://nz.linkedin.com/in/automatem
http://twitter.com/automatem
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
Jochen Daum
2012-09-29 20:52:44 UTC
Permalink
Hi Freddy,
Post by Frediano Ziglio
Post by Jochen Daum
Sorry,
am I supposed to use the HEAD of 0.91 branch or the nightly snapshot?
Kind Regards,
Jochen
Take the git HEAD.
Sorry, could you provide link. I can't find anything relating to git
on freetds.org and there seem to be many forks on github?

Jochen
Frediano Ziglio
2012-09-29 22:36:29 UTC
Permalink
Post by Jochen Daum
Hi Freddy,
Post by Frediano Ziglio
Post by Jochen Daum
Sorry,
am I supposed to use the HEAD of 0.91 branch or the nightly snapshot?
Kind Regards,
Jochen
Take the git HEAD.
Sorry, could you provide link. I can't find anything relating to git
on freetds.org and there seem to be many forks on github?
Jochen
http://gitorious.org/freetds/freetds

Frediano
Jochen Daum
2012-09-30 21:49:05 UTC
Permalink
Post by Frediano Ziglio
Post by Jochen Daum
am I supposed to use the HEAD of 0.91 branch or the nightly snapshot?
http://gitorious.org/freetds/freetds
I've now done
./autogen.sh --with-tdsver=7.2
make
make install

select [Attachment].[attaFilename], [Attachment].[attaContent] from
[Attachment] WHERE ([Attachment].[attaId] = 10239)

works now, this is the minimum data I need.

However

select [Attachment].[attaId], [Attachment].[attaRefTable],
[Attachment].[attaRefKey], [Attachment].[attaHidden],
[Attachment].[attaFilename], [Attachment].[attaContent],
[Attachment].[attaAdded], [Attachment].[attaAddedBy],
[Attachment].[attaComments], [Attachment].[attaDocumentCode]
FROM [Attachment]
WHERE ([Attachment].[attaId] = 10239)

doesn't work, it outputs

Aborted (core dumped)

token.c:2304:tds_process_row(): reading column 6
token.c:2049:tds_get_data: type 111, varint size 1
token.c:2110:tds_get_data(): wire column size is 8
token.c:2304:tds_process_row(): reading column 7
token.c:2049:tds_get_data: type 39, varint size 2
token.c:2110:tds_get_data(): wire column size is 6
token.c:2304:tds_process_row(): reading column 8
token.c:2049:tds_get_data: type 39, varint size 2
token.c:2110:tds_get_data(): wire column size is 0
token.c:2304:tds_process_row(): reading column 9
token.c:2049:tds_get_data: type 39, varint size 2
token.c:2110:tds_get_data(): wire column size is 5
util.c:156:Changed query state from READING to PENDING
odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 1
odbc.c:3535: result_type=4040, TDS_DONE_COUNT=10, TDS_DONE_ERROR=2
odbc.c:3605:odbc_process_tokens: returning result_type 4040
convert_tds2sql.c:164:odbc_tds2sql: src is 56 dest = 1
convert_tds2sql.c:290:odbc_tds2sql: outputting character data destlen = 10
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 48 dest = 1
convert_tds2sql.c:290:odbc_tds2sql: outputting character data destlen = 3
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 61 dest = 1
convert_tds2sql.c:290:odbc_tds2sql: outputting character data destlen = 23
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
error.c:412:odbc_errs_add: "Data truncated"
error.c:517:SQLGetDiagRec(3, 0xe9bcc0, 1, 0x7fff61c8bab0,
0x7fff61c8b684, 0x7fff61c8b8b0, 512, 0x7fff61c8b688)
error.c:566:SQLGetDiagRec: "[FreeTDS][SQL Server]Data truncated"
error.c:517:SQLGetDiagRec(3, 0xe9bcc0, 2, 0x7fff61c8bab0,
0x7fff61c8b684, 0x7fff61c8b8b0, 512, 0x7fff61c8b688)
error.c:517:SQLGetDiagRec(3, 0xe9bcc0, 1, 0x7fff61c8bc10,
0x7fff61c8b808, 0x7fff61c8b810, 1024, 0x7fff61c8b80e)
error.c:566:SQLGetDiagRec: "[FreeTDS][SQL Server]Data truncated"


Kind Regards,

Jochen
Post by Frediano Ziglio
Frediano
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
--
P.S.: Latest newsletter: Website application reporting - an overview -
http://eepurl.com/pKrAD

Kind Regards,

Jochen Daum

"There is no shortcut to anywhere worth going" - Beverly Sills

Automatem Ltd
Phone: +64 9 630 3425
Mobile: +64 21 567 853
Email: jd at automatem.co.nz
Website: www.automatem.co.nz
Skype: jochendaum
http://nz.linkedin.com/in/automatem
http://twitter.com/automatem
Frediano Ziglio
2012-10-01 08:02:02 UTC
Permalink
Post by Jochen Daum
Post by Frediano Ziglio
Post by Jochen Daum
am I supposed to use the HEAD of 0.91 branch or the nightly snapshot?
http://gitorious.org/freetds/freetds
I've now done
./autogen.sh --with-tdsver=7.2
make
make install
select [Attachment].[attaFilename], [Attachment].[attaContent] from
[Attachment] WHERE ([Attachment].[attaId] = 10239)
works now, this is the minimum data I need.
However
select [Attachment].[attaId], [Attachment].[attaRefTable],
[Attachment].[attaRefKey], [Attachment].[attaHidden],
[Attachment].[attaFilename], [Attachment].[attaContent],
[Attachment].[attaAdded], [Attachment].[attaAddedBy],
[Attachment].[attaComments], [Attachment].[attaDocumentCode]
FROM [Attachment]
WHERE ([Attachment].[attaId] = 10239)
doesn't work, it outputs
Aborted (core dumped)
Really bad!

The easier thing is to issue these commands

# ulimit -c unlimited
# <execute your program>
# gdb <executable> <core file>
Post by Jochen Daum
bt full
(core file is produced by the executable when it crash). I added
another fix to bsqlodbc, it could be that you have an empty string
column ('').

Frediano
Post by Jochen Daum
token.c:2304:tds_process_row(): reading column 6
token.c:2049:tds_get_data: type 111, varint size 1
token.c:2110:tds_get_data(): wire column size is 8
token.c:2304:tds_process_row(): reading column 7
token.c:2049:tds_get_data: type 39, varint size 2
token.c:2110:tds_get_data(): wire column size is 6
token.c:2304:tds_process_row(): reading column 8
token.c:2049:tds_get_data: type 39, varint size 2
token.c:2110:tds_get_data(): wire column size is 0
token.c:2304:tds_process_row(): reading column 9
token.c:2049:tds_get_data: type 39, varint size 2
token.c:2110:tds_get_data(): wire column size is 5
util.c:156:Changed query state from READING to PENDING
odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 1
odbc.c:3535: result_type=4040, TDS_DONE_COUNT=10, TDS_DONE_ERROR=2
odbc.c:3605:odbc_process_tokens: returning result_type 4040
convert_tds2sql.c:164:odbc_tds2sql: src is 56 dest = 1
convert_tds2sql.c:290:odbc_tds2sql: outputting character data destlen = 10
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 48 dest = 1
convert_tds2sql.c:290:odbc_tds2sql: outputting character data destlen = 3
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 61 dest = 1
convert_tds2sql.c:290:odbc_tds2sql: outputting character data destlen = 23
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
convert_tds2sql.c:164:odbc_tds2sql: src is 167 dest = 1
error.c:412:odbc_errs_add: "Data truncated"
error.c:517:SQLGetDiagRec(3, 0xe9bcc0, 1, 0x7fff61c8bab0,
0x7fff61c8b684, 0x7fff61c8b8b0, 512, 0x7fff61c8b688)
error.c:566:SQLGetDiagRec: "[FreeTDS][SQL Server]Data truncated"
error.c:517:SQLGetDiagRec(3, 0xe9bcc0, 2, 0x7fff61c8bab0,
0x7fff61c8b684, 0x7fff61c8b8b0, 512, 0x7fff61c8b688)
error.c:517:SQLGetDiagRec(3, 0xe9bcc0, 1, 0x7fff61c8bc10,
0x7fff61c8b808, 0x7fff61c8b810, 1024, 0x7fff61c8b80e)
error.c:566:SQLGetDiagRec: "[FreeTDS][SQL Server]Data truncated"
Kind Regards,
Jochen
Post by Frediano Ziglio
Frediano
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
--
P.S.: Latest newsletter: Website application reporting - an overview -
http://eepurl.com/pKrAD
Kind Regards,
Jochen Daum
"There is no shortcut to anywhere worth going" - Beverly Sills
Automatem Ltd
Phone: +64 9 630 3425
Mobile: +64 21 567 853
Email: jd at automatem.co.nz
Website: www.automatem.co.nz
Skype: jochendaum
http://nz.linkedin.com/in/automatem
http://twitter.com/automatem
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
Jochen Daum
2012-11-21 09:12:57 UTC
Permalink
Sorry for revisiting this only after such a long while.

Recompiling the 0.91 branch has fixed the crash problem.

I'm still stuck with some other problems now, but will ask with a
separate subject line.

Kind Regards,

Jochen

Loading...