Just an ocean and most of a continent ;-)

>Perhaps we are less apart than it seems.
>
>IMO:
>the logging interface you call should be totally under your control - perhaps modelled after an interface of MS, but that is a dev decision.
>
>Implementing the logging behavior MIGHT be done reusing EWT. Doubtful if EWT is ***always*** better - a simple counter incremented in-thread probably is faster than delegating such a task to another thread. Even saving a HighPerformanceCounter result in a C-array and incrementing the pointer to next slot might still be faster and probably the time needed is not less constant then that of a delegate to another thread.
>
>Having a base behaviour totally under your control and using another behaviour depending on some external governor (config XML or program internal) would also be in my design.
>
>Logging does NOT automatically imply for me always hitting the disc with some information piped in more or less structured way - it implies a call to an interface (perhaps embedded in preprocessor directives where available or hooked to minimally invasive calls where the first is not available, but function overloading is or a call to a standard method of a class loaded via factory or or ...) ;-)
>which enables the dev to follow program execution in a manner fitting to the problem. And yes, the fallback/default option should be a self-wriiten pipe to disc which will never fail ;-)
>
>
>
>>Logging should be mostly dead. It's slow, blocks the application, and requires external resources. ETW is built into Windows, happens on a different thread, is VERY fast, and allows you to capture lots of different things.
>>
>>
>>>disagree ;-)
>>>logging before and after each Getdescription/Add linepair might establish if those errors occur
>>>somewhat randomly distributed across a dataload-weighted mean
>>>or
>>>clump on few/one particular table.
>>>In second case, I'd start searching on the server, in first I's look at cable/network issues first.
>>>
>>>