An error has occured whilst saving the Chaser Details :
System.ApplicationException: Database Error Adding Chaser Entry —> System.Data.SqlClient.SqlException: The transaction log for database ‘sotadata_db’ is full due to ‘LOG_BACKUP’. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout, Boolean asyncWrite) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry) at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at SOTA.AddChaserEntry.AddSWLChaserEntry(SqlConnection dbConnection, Int32 userID, Int32 summitID, DateTime activationDate, String timeOfDay, String ownCallsign, String otherCallsign, String notes, String band, String mode, Boolean isSWL, String tableName) in c:\SOTA\SOTADATABASE_Net45\AddChaserEntry.cs:line 323 — End of inner exception stack trace — at SOTA.AddChaserEntry.AddSWLChaserEntry(SqlConnection dbConnection, Int32 userID, Int32 summitID, DateTime activationDate, String timeOfDay, String ownCallsign, String otherCallsign, String notes, String band, String mode, Boolean isSWL, String tableName) in c:\SOTA\SOTADATABASE_Net45\AddChaserEntry.cs:line 339 at SOTA.AddChaserEntry.AddEntry(SqlConnection dbConnection, Int32 userID, Int32 summitID, DateTime activationDate, String timeOfDay, String ownCallsign, String otherCallsign, String notes, String band, String mode) in c:\SOTA\SOTADATABASE_Net45\AddChaserEntry.cs:line 238 at SOTA.AddChaser2.Button1_Click(Object sender, EventArgs e) in c:\SOTA\SOTADATABASE_Net45\AddChaser2.aspx.cs:line 166
Well it was but isn’t anymore.
Of course, this can’t happen as there is a task that runs every day to do some log cleaning. Which makes me think the log cleaning task hasn’t run. Yet another thing to check…
EDIT: yet the task was run. “Something is rotten in the state of Denmark…”
Thanks! Sorry for the cut and paste, but I thought it might be more useful?
Thanks for all you do!
“Every cloud…” as they say.
There is a task that runs every 24hours that, amongst other things, ensures that the transaction log never fills up. It’s been running fine for some time so the fact there was an unexpected error means that something, somewhere has changed. There are a group of database management tasks that run and they email me if there is an issue. Typically these faults happen because something else was happening on the shared server and it was running slower than normal due to load or whatever. Anyway, I’ve not had any problem emails for March which is fine as I expect, based on historical performance, 1 email a month. The fix is normally to rerun the task and that is that.
I had a look this morning and one task had started but failed. There was no fault info in the log, just that it had had an error and stopped. I worked back through the logs and the last time this task succeeded was March 3rd. What was more annoying was there was no email being sent. Something breaking around the 1st of the month always indicates a problem with the association monthly update data. Thus it was that I had managed to add an association with no data when creating 4O. This beautifully exercised a corner case in the generate AM reports which generated 164 reports for the valid associations then got a blank association and instead of stopping, continued with the next association which doesn’t exist. It continued getting non-existent associations and would have attempted to generate an AM report for the next 4294967132 associations that don’t exist. However, the task timed out as it was spinning away but not generating any data. The next thing the task does is generate the band/mode activity reports and finally cleans up the transaction log. Having timed out, no new band/mode reports were produced and no log cleanup took place. Given enough time, the log fills out to 2GB of transaction history and then the DB engine stops any more changes to the DB as it can no longer log the change. This results in the error seen.
The routine to generate the reports needs its logic cleaning so it doesn’t try to keep running until the universe dies of heat-death but the short term fix is to remove the bogus association. Also the task that was failing but not saying so needs a check over too. But with the bogus association removed, everything looks to be running as shonkily as it always does. Bit of a classic fault case with several events needing to stack up to cause the actual failure. The lack of noise that there was a problem is the most troubling.