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 |
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] |
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 |
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 > |
Free forum by Nabble | Edit this page |