There's not much to go on in your question.
But as a start I would check that you have the error source configured to use a non-database listener (e.g. flat file or Event Log). If you are using a configuration file it would look like:
<listeners>
<add source="Logging Quick Start" formatter="Text Formatter"
log="" machineName="." listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FormattedEventLogTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=null"
traceOutputOptions="None" filter="All" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FormattedEventLogTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=null"
name="Event Log Destination" />
</listeners>
<specialSources>
<errors switchValue="All" name="Logging Errors & Warnings">
<listeners>
<add name="Event Log Destination" />
</listeners>
</errors>
</specialSources>
If (or once) you have that set up then try to log something to the database listener and check to see if you are getting any errors logged indicating why the database listener is not working.
If I were to guess I would put my money on some sort of connection issue.
If you think the problem is with SQL then you can start the SQL Server Profiler to trace the SQL Server activity. You should be able to see the connection coming in and the SQL being executed. If you don't see any activity for the connection and stored procedure then you know that SQL Server is not being called. This would mean that the issue is not with SQL Server/stored procedure but with the code, configuration, permissions, firewall, etc.