Fixing DNN Errors that are Related to Search Scheduler > Mitchel's Personal Web Portal

Current Articles | Categories | Search | Syndication

Fixing DNN Errors that are Related to Search Scheduler
By Mitchel Sellers on Wednesday, July 18, 2007 @ 4:09 AM

2643 Views :: 27 Comments ::

I have noticed a number of posts recently on the DotNetNuke.com forums regarding numerous errors being reported in the event log relating to portal id of -1 and typically with a InnerException of "Value cannot be null. Parameter name: type". This issue can become very annoying and can have an actual effect on your sites performance as when the size of the event log grows you will start to notice performance slow downs. This article will discuss the root cause of the issue and a solution.

Cause

The root cause of this issue appears to be traced to an issue with the DNN Installer included in version 4.5.3. When the installer loads a new module to a DNN site it checks for the supporting of the 3 optional interfaces (IPortable, ISearchable, and IUpgradable), it then populates a database value to indicate the supported feature. The bug is that if the installer cannot determine the support is is placing a -1 value in this field rather than a 0. I personally think this is also a bug in the search indexer as if -1 is not valid it should not be checking them, but regardless this is what is causing the problem.

The Fix

As explained above the problem is quite simple, luckily the resolution is just the same. You can simply run the blow query to update the DesktopModules table to fix any incorrect entries.

UPDATE DesktopModules
SET SupportedFeatures = 0
WHERE SupportedFeatures = -1

This is a very simple update query where we are simply changing the value to 0 where it is currently -1. You will need to modify this query to append any object qualifier that you might have listed for your specific database. After performing this change you should notice that the errors will go away!


	Share/Save This Article
	Use the below controls to save this article to one of many popular social bookmarking sites!


	Article Rating
	12345

Article Comments

By Tom Harris @ Wednesday, July 18, 2007 7:30 AM

That was driving me crazy! Thanks for the great, simple, mental health saving solution.
Tom

By Déclic Vidéo FX @ Wednesday, July 18, 2007 10:50 AM

GREAT !!!! It was bothering me for months !! Thanks so much.

Déclic Vidéo FX

By Déclic Vidéo FX @ Thursday, July 19, 2007 7:24 AM

Hello Mitchel,

I am very happy, but it would be fantastic if the "second error" is also removed. For me, an error is still there (it was appearing at the same time that the other one - probably also linked to the scheduler ??)

AssemblyVersion: -1
PortalID: -1
PortalName:
UserID: -1
UserName:
ActiveTabID: -1
ActiveTabName:
RawURL:
AbsoluteURL:
AbsoluteURLReferrer:
UserAgent:
DefaultDataProvider:
ExceptionGUID:
InnerException: Unhandled Error:
FileName:
FileLineNumber: -1
FileColumnNumber: -1
Method:
StackTrace:
Message: System.Exception: Unhandled Error: ---> System.Web.HttpException: Request timed out.--- End of inner exception stack trace ---
Source:

By Mitchel Sellers @ Thursday, July 19, 2007 8:58 AM

I have a feeling that the error is also linked to the scheduler, however, it is a timeout issue and those are not necessarily easy to track down.

By Déclic Vidéo FX @ Friday, July 20, 2007 9:11 AM

Ok, I have submitted it to the DNN team....
http://www.dotnetnuke.com/Community/Forums/tabid/795/mid/2108/threadid/154132/scope/posts/Default.aspx

DV

By Darnell Jordan @ Sunday, July 22, 2007 9:08 AM

Great fix Mitchell! Worked perfectly!!

By Frank @ Thursday, July 26, 2007 4:29 AM

Thanks Mitchel... your solution worked well for me.

By David @ Friday, August 03, 2007 6:28 AM

Hey guys, I really don't want to sound like an idiot but I need to know. How exactly does one go about doing this fix? Like, if someone would? Step by step for people like me..

Thanks,

David

By Mitchel Sellers @ Friday, August 03, 2007 6:41 AM

You can run the script from the Host -> SQL menu when logged in as host.

By erik van ballegoij @ Tuesday, August 14, 2007 2:44 PM

Mitchel,

This is just to let you know that this has been fixed for dnn 4.6.0. See this Gemini issue: http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=5970

Thanks for this find

By IowaComputerGurus Host @ Tuesday, August 14, 2007 3:36 PM

Erik,

Thanks for the notification!!

By Bill @ Sunday, August 19, 2007 9:30 AM

Hi Mitchel,

I appreciate this fix...

Thank you!

Bill

By Paul Fijma @ Tuesday, August 28, 2007 8:47 AM

found numerous other annoyances to get rid of this one... finally it's "fixed". Thanks for posting it!

By Richard Edwards @ Tuesday, August 28, 2007 10:22 AM

Thanks Mitchel. Saved me a bunch of headaches.

By M. Lee @ Thursday, August 30, 2007 2:22 PM

I ran the query from Host > SQL .. now what concerns me is that I haven't had any log entries since ... it's been over an hour .. even login entries are not shown. Please advise.

By Mitchel Sellers @ Thursday, August 30, 2007 2:43 PM

THis script ONLY will affect entries for the scheduler errors, it will NOT have any affect on other logging items.

By Paul @ Friday, September 07, 2007 11:31 PM

David made the following comment:
Hey guys, I really don't want to sound like an idiot but I need to know. How exactly does one go about doing this fix? Like, if someone would? Step by step for people like me..

Can I hope for more of the same. I curt and pasted the above script into host SQL and recieved "There is an error in your script"
I note the Mitchel comments that 'you will need to append any object qualifers" I have DNN_ as an object qualifier. how do I appen this?
Do I run this as script or simple execute?

Thanks,

Paul

By Mitchel Sellers @ Saturday, September 08, 2007 8:46 AM

Paul,

If you have DNN_ as your object qualifier, use the following when running the script from the SQL Page.

UPDATE DNN_DesktopModules
SET SupportedFeatures = 0
WHERE SupportedFeatures = -1

By Paul @ Sunday, September 09, 2007 2:22 PM

thanks Mitchel.
Sometimes the obvious takes longer to see.
The log file has reduced dramtically.
Paul

By Chinh Ho @ Saturday, September 29, 2007 1:33 AM

Can you help me now
Event Log : Error

DotNetNuke.Services.Exceptions.ModuleLoadException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe) at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery(SqlConnection connection, CommandType commandType, String commandText, SqlParameter[] commandParameters) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery(String connectionString, CommandType commandType, String commandText, SqlParameter[] commandParameters) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery(String connectionString, CommandType commandType, String commandText) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery(String connectionString, String spName, Object[] parameterValues) at DotNetNuke.Services.Log.EventLog.DBLoggingProvider.Data.SqlDataProvider.PurgeLog() at DotNetNuke.Services.Log.EventLog.DBLoggingProvider.DBLoggingProvider.PurgeLogBuffer() at DotNetNuke.Services.Log.EventLog.LogController.PurgeLogBuffer() at DotNetNuke.Modules.Admin.Log.LogViewer.Page_Load(Object sender, EventArgs e) --- End of inner exception stack trace ---

Chinh - VietNam

By Mitchel Sellers @ Saturday, September 29, 2007 5:02 AM

This appears to be a timeout issue with the event log.

You could try clearing the table manually using "TRUNCATE TABLE eventLog" (Without the quotes)

By Terp @ Friday, November 09, 2007 3:52 AM

Worked perfectly for me...keep coming back to this one, so I need to write it down in my notes.

Any idea whether all this has worked itself out in 4.7? ...thinking of making the switch, but usually like to wait until the x.x.2 version. :)

By Mitchel Sellers @ Friday, November 09, 2007 9:53 AM

Terp,

This was actually fixed in I believe 4.6.0. They added code in the SqlDataProvider file to fix the current errors, and then with their overhaul to the module installation process fixed the underlying error.

I would have to dig through the data providers to find the exact version but I am quite sure it was 4.6.0

By Fabio @ Saturday, November 24, 2007 4:42 AM

Thank you very much for the help.

We´ve been trying to resolve this issue for a long time.

By Erik Wilkinson @ Wednesday, January 02, 2008 6:25 PM

This was driving me nuts. Thanks for posting the fix.

By Jarmo @ Tuesday, January 22, 2008 6:58 AM

Thanks a MILLION! This was really haunting me for few weeks!

By Robert Stordeur @ Saturday, February 16, 2008 7:23 AM

Thanks! I've been having this issue in too many versions of DNN that I can remember. This stopped the error. BTW, we had already upgraded to 4.6.2 and still had the problem. So it wasn't fixed.

After we ran the SQL, we didn't get the error, but we didn't get any results either. On several DNN installations.

Come to find out that the Search Results module had a cache setting of 1200. After each search, you had to wait 20 minutes b4 the results would change. Set it to 0 and all is well with the world!!!

Click here to post a comment