Jul 15, 2012 at 6:43 AM
Edited Jul 15, 2012 at 6:46 AM
I think you are referring to the stored procedure used by the FormattedDatabaseTraceListener. The public Write methods of the abstract LogWriter class do not return a value so returning data from the Logging Application Block is not part of the design.
For the purpose of users of the Logging Application Block the LogID returned by the WriteLog stored procedure is an internal implementation detail.
If you really need to get at the ID of the newly inserted log record there are a few approaches that you could use:
- Modify the Logging Application Block source code to potentially return a value (although this could be messy and would only really have meaning if a database trace listener is used).
- Create a custom trace listener that sets the LogID so that it is available later by the caller. This could be a ThreadStatic variable or some other type of global variable based on a thread ID or a custom request ID. Another approach would be
to have the custom trace listener add a new ExtendedProperties value for the LogID. For this to work the Write method which accepts a LogEntry would have to always be used.
- Use a custom approach without Enterprise Library that aligns with your exact needs.
None of the approaches is elegant. If pushed I would go with option 2 and write a facade so that callers can easily get the LogID back. Assuming that the custom trace listener adds the LogID to the ExtendedProperties then the facade might look
public int WriteFacade(string message, string category)
LogEntry logEntry = new LogEntry()
Message = message,
// Can optimize and keep an instance reference to this
var logger = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();
object rawId = logEntry.ExtendedProperties["LogId"];
if (rawId != null && int.TryParse(rawId.ToString(), out logId))
Enterprise Library support engineer