Log to secondary when primary is not available

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Configure SQL logging.
2. SQL Connectivity issues (ie.wrong conn.str.)
3. No errors log.

It would be nice to be able to configure secondary log.

Original issue reported on code.google.com by Roland.B...@gmail.com on 17 Apr 2008 at 8:03

[GoogleCodeExporter]

Original comment by azizatif on 17 Apr 2008 at 10:24

• Changed title: Log to secondary when primary is not available
• Added labels: Component-Logic, Component-Persistence, Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

This problem is better resolved by setting up error logging and e-mail 
reporting. If 
error logging fails then usually SMTP will be working and at least one will get 
an e-
mail. If the infrastructure is experiencing SQL and SMTP connectivity issues, 
both 
at the same time, then it should warrant a look into the infrastructure 
problem. 
Adding a secondary logging mechanism won't help much more. Don't you think? 
Creating 
fallback logging is not difficult, but the bigger problem is getting to those 
errors 
back into the log view. Which one do you show? Primary, secondary, both? Would 
you 
agree that the best way to resolve this would be to simply send the exception 
to the 
currently configured trace listeners? That way, one can use the existing 
tracing 
infrastructure as a fallback, which supports an array of listeners and has a 
viewing 
facility available via trace.axd.

Original comment by azizatif on 17 Apr 2008 at 10:35

[GoogleCodeExporter]

I like the orginal poster's idea.

For example, maybe I would like Elmah to...

1st try to log to SqlServer 
2nd try to log to XmlFile
3rd try to log to EventLog

...maybe.

EventLog is a good catch-all because it is always up or the machine is toast.

Just my 2-cents.

-- Mark Kamoski

Original comment by mkamo...@gmail.com on 29 Apr 2009 at 8:18

[GoogleCodeExporter]

I'm just beginning with ELMAH (and I have to say it's great!).  But most of our 
problems lately have been with not getting a connection to Oracle, so obviously 
I can't write the error log to Oracle if I can't get a connection.  So, my 
preference would be to filter the errors by type, and send the Oracle errors to 
the XML log, and the Non-Oracle errors to Oracle, with the log view pulling 
from both the XML and from Oracle (if possible, assuming Oracle is up and 
working).

Original comment by paris1...@gmail.com on 1 Dec 2010 at 10:44

[GoogleCodeExporter]

I released a composite errorlog which address exactly this issue.
You can install it via Nuget or copy it from sources into your projects.

Nuget package: http://nuget.org/packages/Elmah.FallbackErrorLog/
sources on Github: https://github.com/eric-b/Elmah.FallbackErrorLog/

Let me know if you have trouble using it. Feel free to merge it into core Elmah 
if it can resolve this issue.

Original comment by eric....@gmail.com on 5 Feb 2013 at 9:23

[GoogleCodeExporter]

This issue has been migrated to:
https://github.com/elmah/Elmah/issues/58
The conversation continues there.
DO NOT post any further comments to the issue tracker on Google Code as it is 
shutting down.
You can also just subscribe to the issue on GitHub to receive notifications of 
any further development.

Original comment by azizatif on 25 Aug 2015 at 8:16