FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

Yes, if you could narrow it down to a small sample program that demonstrates
the problem, that would be ideal.

Also, are you using the latest release?  I couldn't find anything below that
explicitly says what you are using, but Jim's suggestion to upgrade to 0.61
is a hint that you might be using an old release.  If you aren't running
0.61 (or a newer snapshot), then you probably don't have the latest error
and message dispatching code, and it probably isn't worth even trying to
isolate this problem.

Cheers,
--nick

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org]
Sent: Monday, May 05, 2003 12:39 PM
To: 'FreeTDS Development Group'
Subject: [freetds] RE: INT_CANCEL return from DbLib error handler fails


Thanks, Nick. Sorry for my presumption about others fixing things in open
source projects (I do understand the concept!).

I'm actually using MS SQL Server 200, rather than Sybase, but I would guess
that for this particular problem, it's irrelevant.

My code is being used in a slightly weird environment, so I can't just send
it as is. But the basic idea is that the code opens a DBProcess, and uses it
to call SQL Server. It also caches that DBProcess, and uses it for all
subsequent calls to my code. (The code is in a UNIX daemon, being called by
other processes via queued messages.) Of course, the connection might die or
be killed. It's when this happens that I'm running into the problem: a call
to dbsqlexec, that causes the error handler to be called, just never returns
at all.

If that's not enough to go on, I could create a sample program that
hopefully will demonstrate the problem.

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops AT hepcoe.com    416-597-5055

-----Original Message-----
From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
Sent: Monday, May 05, 2003 11:07 AM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] RE: INT_CANCEL return from DbLib error handler fail s

>From a DB-Library perspective, there are two types of notifications you can
receive when a problem occurs.

If the server detects a problem, it sends a "message" to DB-Library.  This
notification is handed off to the user via a "message handler" callback.
The user installs this callback via "dbmsghandle()".  The return code from
this callback is ignored, and the Sybase docs says the user should always
return 0.  This type of notification works well in FreeTDS, at least in the
most recent releases and snapshots.  FreeTDS calls this a "server message."

If DB-Library itself notices a problem, it invokes an "error handler"
callback.  The user installs this callback via  "dberrhandle()".  The return
code from this callback may be INT_EXIT, or INT_CANCEL.  (There are two
other codes that can can be returned in very special cases, we can ignore
those for now.)  FreeTDS calls this a "client message."

The first important point is that Dan is talking about an error handler, but
Jim was looking at message handler code.  I spent a lot of time separating
these two concepts in FreeTDS...let't not get them mixed up again.

The INT_EXIT case, we handle pretty well (see src/dblib/dbutil.c around line
121).

In the INT_CANCEL case, we just return SUCCEED.  That seems suspicious until
you recall that (in most cases) there is no choice but INT_EXIT or
INT_CANCEL.  In the INT_EXIT case we already exited, so in the INT_CANCEL
case it isn't necessary to "propagate" the return code.  If it returns at
all, we know that the user's error handler returned INT_CANCEL.

The real problem is that while FreeTDS has a concept of an error handler, we
actually invoke the error handler in very few places.  We need to find and
identify everywhere that Sybase OpenClient DB-Library generates an error
handler callback.  In those places, we need to generate an error handler
callback in FreeTDS (e.g. by calling _dblib_client_message()) and then
handle the error appropriately if the handler returned.  See, for example,
the various calls to _dblib_client_message() in dbconvert(), in
src/dblib/dblib.c around line 1677).

As to exactly what Dan't problem is, I couldn't say.  If he provides a small
program that demonstrates the problem (e.g. it behaves correctly with
Sybase's DB-Library but fails with FreeTDS), I can try to fix the particular
problem he is experiencing.

Hopefully that clarifies the situation somewhat (or at least didn't make
things more confusing.)

One last thing, Dan.  The "normal developers" are all unpaid volunteers, and
most of us are interested only in using FreeTDS to solve our own particular
problems.  Unless our problems happen to overlap with your problems, we are
unlikely to fix it for you.  In this case you may luck out, because I do
happen to have a personal interest in our error and message handling code.
But, in general, finding a problem is equivalent to volunteering to fix it.
That's the nature of the beast when dealing with open source projects,
especially small ones like FreeTDS.

Cheers,
--nick


-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org]
Sent: Monday, May 05, 2003 9:53 AM
To: 'FreeTDS Development Group'
Subject: [freetds] RE: INT_CANCEL return from DbLib error handler fails


I wish I had the time to examine and fix this, but I really don't. Isn't
this something the normal developers of the package would be interested in
fixing?

Thanks.

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops AT hepcoe.com    416-597-5055

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK AT bernstein.com]
Sent: Friday, May 02, 2003 5:30 PM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] INT_CANCEL return from DbLib error handler fails

> From: Cooperstock, Dan [mailto:dan.cooperstock AT hepcoe.com]
> Sent: May 2, 2003 2:16 PM
>
> I'm returning in INT_CANCEL from the error handler I set with
> dberrhandle() in a DbLibrary application using FreeTDS.
>
> As I understand it, that should cause working functions, like
> dbsqlexec,
> which threw an error, to get a bad (not SUCCEED) return value.

You understand correctly.  Looking at the code, our implementation is
defective.  Which is odd, because we had a very involved discussion about
this about six months ago.  Apparently we solved the problem in theory but
never got a round tuit.  Maybe the different libraries have conflicting
semantics, and we're not set up for that.

If you're interested in fixing this, you'll need a current snapshot, or at
least upgrade to 0.61.

The relevant function is (assuming it's a server-side message you're talking
about) is tds_process_msg() in src/tds/token.c:2019.  Near the end of that
function, we call the installed handler, but ignore its return code and
return TDS_SUCCEED.

I don't know how fastidious we are about propogating the error back up the
stack.

--jkl

_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.

_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.