AddParameter(command as OracleCommand, "CUR_OUT", OracleDbType.RefCursor, 0, ParameterDirection.Output, true, 0, 0, String.Empty, DataRowVersion.Default, Convert.DBNull);
publicclass OracleParameterMapper : IParameterMapper { readonly OracleDatabase database; public OracleParameterMapper(Database database) { this.database = database as OracleDatabase; } publicvoid AssignParameters(DbCommand command, object[] parameterValues) { if (parameterValues.Length > 0) { GuardParameterDiscoverySupported(); database.AssignParameters(command, parameterValues); } if (CommandType.StoredProcedure == command.CommandType) { bool doesQueryProcedureNeedCursorParameter = true; foreach (OracleParameter parameter in command.Parameters) { if (parameter.OracleType == OracleType.Cursor) { doesQueryProcedureNeedCursorParameter = false; } } if (doesQueryProcedureNeedCursorParameter) { database.AddParameter(command as OracleCommand, "CUR_OUT", OracleType.Cursor, 0, ParameterDirection.Output, true, 0, 0, String.Empty, DataRowVersion.Default, Convert.DBNull); } } } privatevoid GuardParameterDiscoverySupported() { if (!database.SupportsParemeterDiscovery) { thrownew InvalidOperationException( "Parameter Discovery Not Supported"); } } }
EntLibConfig.exe configuration tool as a standalone. If you download the Enterprise Library binaries, it will include the standalone configuration tool. Note that for the executable to work properly it should be distributed with the appropriate Enterprise Library assemblies as well.Can you please let me know if this is a blocking issue, in the sense that no more messages would be logged until the service is restarted?What behavior are you seeing?
The methods in your custom EventSourceclass will be called from multiple places in your~~
application, and possibly from multiple applications if you share the same EventSourceclass. You
should take care when you modify your EventSourceclass, that any changes you make do not have
unexpected consequences for your existing applications. If you do need to modify your EventSource
class, you should restrict your changes to adding methods to support new log messages, and adding
overloads of existing methods (that would have a new event ID). You should not delete or change
the signature of existing methods.
This is especially important in light of the fact that if you have multiple versions of your EventSource
class in multiple applications that are using the Semantic Logging Application Block out-of-process
approach, then the version of the event schema that the host service uses will not be predictable.
You should ensure that you have procedures in place to synchronize any changes to the EventSource
class across all of the applications that share it.
[DeploymentItem("Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll")]
[DeploymentItem("Microsoft.Practices.EnterpriseLibrary.Logging.Database.dll")]
public class Logger : EventSource
{
public static readonly Logger Log = new Logger();
[Event(101, Level = EventLevel.Informational]
public void TestObjectParms(params object[] args)
{
if (IsEnabled()) WriteEvent(101, args);
}
}
object[] testArgs = {"object1","object2","object3"};
Logger.Log.TestObjectParms(testArgs);
EventSource.WriteEvent method which does take params.