maoyuan121 / elmah

Automatically exported from code.google.com/p/elmah
Apache License 2.0
0 stars 0 forks source link

Production issues #196

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Not sure if this is just my current IIS settings, or very particular 
web.config settings, but I have googled around looking for a solution and it 
seems that a few other devs are having the same issue with ELMAH not reporting 
errors in production. Now, I've double/triple/quadruple checked my database to 
make sure the necessary tables, sp's, and permissions are set up in my 
production database, they are. When I run sql profiler there is absolutely no 
traffic from elmah coming over the wire during an exception.

I realize this is probably a long shot asking you guys this, but figured maybe 
there was something fairly obvious I'm missing in a setting due to how many 
people I've come across online that are having the same issue.

Thanks ahead in advance.

Original issue reported on code.google.com by JustinJo...@gmail.com on 8 Jan 2011 at 12:10

GoogleCodeExporter commented 9 years ago
I work in the same environment as the poster.

1. We are using ELMAH in more that on website in Production.  The common 
denominator in all on them not working was that there was no connection string 
entry for ELMAH at the local level.  All our connection strings are set at 
Machine.Config or are inherited via the parent web.config.

This is was successfully resolved when adding in a connection string at the 
same level as ELMAH was begin configured.

Original comment by asubhani on 8 Jan 2011 at 1:31

GoogleCodeExporter commented 9 years ago
So to confirm...

1) ELMAH configuration is local
2) Connection strings are stored in machine.config
3) You are accessing the connection strings by name i.e. <errorLog ... 
connectionStringName="" />

This is interesting... I have done a quick test on my dev machine and it's 
working fine... I tried the following:

1) Set up the MS Access provider locally
2) Log some exceptions
3) Check the .mdb was created in the |DataDirectory|
4) Move the connection string into machine.config
5) View elmah.axd and see that all errors can still be read
6) Log a new exception and test it is logged
7) Amend the connection string in machine.config to write to a new .mdb file
8) Check elmah.axd to ensure there are no errors
9) Log a new exception
10) Check elmah.axd to ensure there is 1 exception
11) Check that the new database file was created in |DataDirectory|

ALL of these tests passed!!

Furthermore, if I remove the connection string completey, and view elmah.axd, I 
get a YSOD saying that Connection String is missing for Access Error Log.

Can you check your elmah.axd and check the last sentence on the page... "This 
log is provided by..." to make sure it is as expected?

Maybe you can also create a page that displays details of all available 
connection strings to be sure that you are getting what you *think* you are 
getting!!

Original comment by jamesdriscoll71 on 10 Jan 2011 at 4:59

GoogleCodeExporter commented 9 years ago

Original comment by jamesdriscoll71 on 19 Feb 2012 at 11:30