Hi

You are not going to be able to trap the error on the server itself. If you
trap it on the client then you can write it to a log table, but then if the
error is to do with the database being corrupted and unwritable or similar
you are stuck.

John

"Jason" <JayCallas@hotmail.com> wrote in message
news:f01a7c89.0310270900.2f8112cd@posting.google.c om...
> Erland Sommarskog <sommar@algonet.se> wrote in message
news:<Xns9420923643DYazorman@127.0.0.1>...
> > Shervin Shapourian (ShShapourian@hotmail.com) writes:
> > > I'm looking for a solution to log all errors on server side, either in
> > > server's event log or in a table. I'm gonna read the article you sent
me.
> >
> > Alas, this is not possible. You need to have a co-operating client.
>
> I have been taking the approach that whatever could be done on the
> server SHOULD be done on the server. (i.e. Use the scheduler in SQL
> Agent to kick off jobs, have the jobs write out to tables for logging
> since errors cannot REALLY be captured, and so on...)
>
> Is this wrong? Should I be using a third-party schedules and sending
> ISQL (I think that is the command) or regular ADO type scripts to kick
> off stored procedures? Is there a policy or concept of when to
> separate jobs from server?