Hi,

Any ideas why a threaded application can't

DISCONNECT :connection or CLOSE DATABASE

when SQLCODE was -439 before a sqlbreak(), and 0 after the sqlbreak() ?

it just encounters another -439 error, even if sqlbreak() is called before.

sqlbreakcallback(0L,callback_func) doesn't even call the callback_func
as it's supposed to.

maybe a socket timeout ? would a signal(SIGPIPE, SIG_IGN) help ?
onstat -g ses still shows the connection though

maybe a bug in the engine ? how could i get around this ?

Thanks
Corne'

!Exclude Disclaimer!

The callback functions wasn't even called when i used 0 as timeout.
Maybe the client loses the signal handler, or gets blocked ?

Not using shared memory connection. using onsoctcp

The only thing that seems to work, is to kill any thread that got the
-439 possible runaway process, and create a new thread.


Andy Lennard wrote:
> In message <3F4507B7.9090302@reach.co.za>, Corne' Cornelius
> <cornec@reach.co.za> writes
>
>>Hi,
>>
>>Any ideas why a threaded application can't
>>
>>DISCONNECT :connection or CLOSE DATABASE
>>
>>when SQLCODE was -439 before a sqlbreak(), and 0 after the sqlbreak() ?
>>
>>it just encounters another -439 error, even if sqlbreak() is called before.
>>
>>sqlbreakcallback(0L,callback_func) doesn't even call the callback_func
>>as it's supposed to.
>>
>
>
> My manual says that if the timeout is 0, then the callback function
> executes immediately, and then 'over and over again'.
>
> However it also says that the callback function will never be called if
> you use a shared memory connection.
>
> I guess the application is correctly built threaded..
>
>
>>maybe a socket timeout ? would a signal(SIGPIPE, SIG_IGN) help ?
>>onstat -g ses still shows the connection though
>>
>>maybe a bug in the engine ? how could i get around this ?
>>
>>Thanks
>>Corne'
>>
>>!Exclude Disclaimer!
>>
>
>