> Table logging is transactional, so it won't work as expected when a ROLLBACK is performed. IMO this is therefore not an option.
Agreed. We only use this for logging successes. We handle errors in the client code.
> A non-transactional variation is possible though by using a proxy table mapped to an O/S file.
These are banned where I work (I've never been anywhere where they're allowed ? Does anyone use them?)
And even if they weren't banned we couldn't use them as we can't log on to the database server.
> Another item missing from the list is using dbcc logprint or dbcc printolog (pints strings to the ASE errorlog, this can sometimes be useful).
Maybe useful for some poeple but we can't really log the number of message we want this way.
> As for syb_sendmsg, I think I recall there is little overhead as this is pretty lightweight (it's UDP , not TCP). But you need a listener on the other side, which has disadvantages,
That's true but there are many logging systems which do this anyway.
In fact syslogd uses this so in theory everyone could get this for free. One place I worked had a team of people who would do overnight call outs if they received a UDP message. Splunk uses UDP. I've seen mindalign connection build using it. (I think this is the one feature that MS-SQL hasn't implemented)