FreeTDS Development Group

[bico hamalah <biconorris AT yahoo.com>]

I am able to connect through isql.

however, from oracle to ms sql through database link, i get:

SQL> SELECT * FROM Banks@EIMS;
SELECT * FROM Banks@EIMS
                    *
ERROR at line 1:
ORA-28500: connection from ORACLE to a non-Oracle system returned this 
message:
[unixODBC][FreeTDS][SQL Server]Unable to connect to data
source[unixODBC][FreeTDS][SQL Server]Adaptive Server connection
failed[unixODBC][FreeTDS][SQL Server]Unexpected EOF from the server
ORA-02063: preceding 2 lines from EIMS
>From freddy77 AT gmail.com  Fri Sep 28 03:00:35 2012
Return-Path: <freddy77 AT gmail.com>
X-Original-To: freetds AT lists.ibiblio.org
Delivered-To: freetds AT lists.ibiblio.org
Received: by lists.ibiblio.org (Postfix, from userid 20217)
        id AE1C6E8A74; Fri, 28 Sep 2012 03:00:35 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 
mailman1.ibiblio.org
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,
        DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham 
version=3.3.1
Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com
        [209.85.220.49])
        by lists.ibiblio.org (Postfix) with ESMTP id 2B164E8A72
        for <freetds AT lists.ibiblio.org>; Fri, 28 Sep 2012 03:00:33 -0400 (EDT)
Received: by padbi5 with SMTP id bi5so2150649pad.36
        for <freetds AT lists.ibiblio.org>; Fri, 28 Sep 2012 00:00:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.90.38 with SMTP id bt6mr15259137pab.53.1348815633396; Fri,
        28 Sep 2012 00:00:33 -0700 (PDT)
Received: by 10.68.4.67 with HTTP; Fri, 28 Sep 2012 00:00:33 -0700 (PDT)
In-Reply-To: <20120926233609.7009bb52.jklowden AT freetds.org>
References: 
<CAPeqxCdBH0=S-sFMpTw_w+TsoOz4N7v6ugd5vHZ5hyAxc6vkfw AT mail.gmail.com>
        <505F96E4.7080901 AT lurcher.org>
        <CAPeqxCfcwGZqAy_xCL405jWoA9eO3_GD8w_9GiSbT_5YN-BmZA AT mail.gmail.com>
        <20120924102135.37cd6e43.jklowden AT freetds.org>
        <CAPeqxCcwJiBtXXnmJwXCHR_Y4o8NzoUEz0Z05J4S-zvyQT0yRA AT mail.gmail.com>
        <20120924230500.16819dd3.jklowden AT freetds.org>
        <CAPeqxCcrfGTTbW8ZM+bc0JRxydTKpXDfcE6A11_OFBE5fan98g AT mail.gmail.com>
        <20120926233609.7009bb52.jklowden AT freetds.org>
Date: Fri, 28 Sep 2012 08:00:33 +0100
Message-ID: 
<CAHt6W4d4hHbn_70=c=+NuAyWBN9Do-vN++xRvNdfqbTQSEQUSg AT mail.gmail.com>
From: Frediano Ziglio <freddy77 AT gmail.com>
To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [freetds] Fwd: [unixODBC-support] PHP PDO unixODBC FreeTDS SQL
 Server text column size
X-BeenThere: freetds AT lists.ibiblio.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
List-Id: FreeTDS Development Group <freetds.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/freetds>,
        <mailto:freetds-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/freetds>
List-Post: <mailto:freetds AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/freetds>,
        <mailto:freetds-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2012 07:00:35 -0000

2012/9/27 James K. Lowden <jklowden AT freetds.org>:
> On Wed, 26 Sep 2012 09:31:08 +1200
> Jochen Daum <jd AT automatem.co.nz> wrote:
>
>> 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, 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,
>
>>       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