Skip to Content.
Sympa Menu

freetds - [freetds] FreeTDS0.91 connection error

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: bico hamalah <biconorris AT yahoo.com>
  • To: "freetds AT lists.ibiblio.org" <freetds AT lists.ibiblio.org>
  • Subject: [freetds] FreeTDS0.91 connection error
  • Date: Thu, 27 Sep 2012 03:22:15 -0700 (PDT)

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



  • [freetds] FreeTDS0.91 connection error, bico hamalah, 09/27/2012

Archive powered by MHonArc 2.6.24.

Top of Page