Hi Richard,
>> Burying my head in the sand by suppressing the error messages is not something I like doing, if any code I produce throws an error message I like to know about it so the suggestion is not an option
I'm not saying you should ignore them - just that they should not pop up as MESSAGES because that will break the server.
The server relies on Events, and while the MESSAGE is open events are lost. Displaying messages on the server side is thus very bad. Feel free to log all the calls into that method, and then take what ever action you see fit.
(Personally, I use MessageBox to log the error, and not display it.)
>> Why is it trying to close the connection as soon as the page is or just after the page has been loaded
because that's how it works. Each request makes a connection, issues a request, gets a response and closes.
>> especially as the Keep-Alive is set?
Keep-alive is a suggestion, not a requirement for the server. In NetTalk's case each request is handled by a different thread, so there's no benefit to keeping the connection open.
>> Closing the connection will lose the session ID and everything relevent to the user at the time.
sorry - no. The connection is always fleeting. the connection has nothing to do with the session. _all_ connections close immediately after the response has been sent.
The errors you see in this case;
>> Unable to close connection -34
means that the browser has already closed the connection. Clearly one end will close the connection first, sometimes it's the server, sometimes it's the client. It throws a message into ErrorTrap because it has been instructed to close the connection, but that failed because the connection was already closed.
>> Error Sending data -40.
is likely the same thing - if the browser closes the connection before the reply is sent to them, then you try and respond on an already closed connection, then you'll get an error. Since there's nothing you can do (the connection is already closed) the error has no meaning.
>> What I've also seen is the occasional packet being processed in the debugger
If you mean the Clarion debugger - then the debugger itself is likely causing the error. You cannot debug the server in the debugger because of time-related issues. For example the browser will time out in 30 seconds. Also you've got incoming events coming in on various threads etc, then palmed off to worker threads. If you want to debug then use the _trace command, along with Debugview. (which is maybe what you meant.)
Cheers
Bruce