ODBC function sequence error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ODBC function sequence error

Eric Langjahr
Hello.  I wonder if anyone has encountered a function sequence error
using ODBC with Dolphin.  I have run into a few and mostly been able
to work around them.

However this one has me stumped.  I am interested in surpressing some
of the warning messages that are generated when connections are opened
(like context changes).

The following code seems to fail consistently.  I checked it in a
clean image and even after doing DBConnection invalidateAll.

I think it is symptomatic of an underlying problem in the ODBC library
but I am not sure what (yet<g>)

connection isNil ifTrue: [
        [connection := (DBConnection new) dsn: 'DATABASE'; uid: 'UID';
pwd: 'PW'; connect]
                on: DBWarning do: [:warning |
                ].
        ].

I am not sure why wrappering this code with the on:do: should cause a
problem.  Needless to say without the on:do everything works fine.

Try this in a workspace without the connection isNil if True: block
and it still fails.

I am using ODBC 3.5x and SQL Server 2000 Personal on NT 2000 SP1 Pro

Any ideas, suggestions or thoughts are appreciate<g>.

Eric


Reply | Threaded
Open this post in threaded view
|

Re: ODBC function sequence error

Bill Schwab-2
Eric,

At the wild guess level, your trapping of the warning might be causing it to
resume execution elsewhere rather than finishing what the code was doing.
<selfDeprecation>That's a lousy way to say it</selfDeprecation> so I'll try
again.  For my theory to hold up, you'd have to get a some kind of message
box telling you that something went wrong, after which the code would resume
what it was doing and give you the result - is that what happens w/o the
#on:do:?  If so, then you might try placing a #resume (or maybe it's more
tricky than that - please post again if you're having trouble and I can look
for some related code of mine) in your error handler.  However, the real fix
is probably going to be to suppress the warning all together.

Not too long ago, somebody pointed me in the right direction on a problem
that I thought was a driver problem.  It turned out to be a DB warning that
presents a message box only in a development session.  So, your problem
might go away on its own if you deploy, or you can find that conversation in
the archives and make the change that was recommended to me.

If you're still stuck after this, it might help to see the call stack that
you get.  It will be either in your Dolphin.errors file, or you can grab it
from the walkback.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ODBC function sequence error

Blair McGlashan
In reply to this post by Eric Langjahr
Eric

You wrote in message news:[hidden email]...

> Hello.  I wonder if anyone has encountered a function sequence error
> using ODBC with Dolphin.  I have run into a few and mostly been able
> to work around them.
>
> However this one has me stumped.  I am interested in surpressing some
> of the warning messages that are generated when connections are opened
> (like context changes).
>
> The following code seems to fail consistently.  I checked it in a
> clean image and even after doing DBConnection invalidateAll.
>
> I think it is symptomatic of an underlying problem in the ODBC library
> but I am not sure what (yet<g>)
>
> connection isNil ifTrue: [
> [connection := (DBConnection new) dsn: 'DATABASE'; uid: 'UID';
> pwd: 'PW'; connect]
> on: DBWarning do: [:warning |
> ].
> ].

Bill is on the right track. If you trap an exception, even a resumable one
like a Warning, and specify no handler action, then the default behaviour is
to continue execution after the handler, not at the point where the
exception was raised. If you place "warning resume" in the exception handler
then you will not be pulling the rug from under DBConnection's feet, and it
will work more satisfactorily.

Alternatively you might like to take a leaf out of D4's book and move
DBWarning to be a subclass of Notification, rather than Warning (I don't
recall if any other tweaking is needed). In that configuration the "success
with info" reports are handled more sensibly and don't result in unwanted
message boxes.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: ODBC function sequence error

Eric Langjahr
Guys - good points<g>.  I guess I made the assumption, without
looking, that there was nothing else important happening after the
DBWarning was signaled.  That was obviously untrue<g>.



On Thu, 18 Jan 2001 22:25:54 -0000, "Blair McGlashan"
<[hidden email]> wrote:

>Eric
>
>You wrote in message news:[hidden email]...
>> Hello.  I wonder if anyone has encountered a function sequence error
>> using ODBC with Dolphin.  I have run into a few and mostly been able
>> to work around them.
>>
>> However this one has me stumped.  I am interested in surpressing some
>> of the warning messages that are generated when connections are opened
>> (like context changes).
>>
>> The following code seems to fail consistently.  I checked it in a
>> clean image and even after doing DBConnection invalidateAll.
>>
>> I think it is symptomatic of an underlying problem in the ODBC library
>> but I am not sure what (yet<g>)
>>
>> connection isNil ifTrue: [
>> [connection := (DBConnection new) dsn: 'DATABASE'; uid: 'UID';
>> pwd: 'PW'; connect]
>> on: DBWarning do: [:warning |
>> ].
>> ].
>
>Bill is on the right track. If you trap an exception, even a resumable one
>like a Warning, and specify no handler action, then the default behaviour is
>to continue execution after the handler, not at the point where the
>exception was raised. If you place "warning resume" in the exception handler
>then you will not be pulling the rug from under DBConnection's feet, and it
>will work more satisfactorily.
>
>Alternatively you might like to take a leaf out of D4's book and move
>DBWarning to be a subclass of Notification, rather than Warning (I don't
>recall if any other tweaking is needed). In that configuration the "success
>with info" reports are handled more sensibly and don't result in unwanted
>message boxes.
>
>Regards
>
>Blair
>