Skip to Content.
Sympa Menu

freetds - RE: [freetds] RE: INT_CANCEL return from DbLib error handler fail s

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Castellano, Nicholas" <Nicholas_Castellano AT acml.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] RE: INT_CANCEL return from DbLib error handler fail s
  • Date: Mon, 5 May 2003 11:07:07 -0400

>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.






Archive powered by MHonArc 2.6.24.

Top of Page