Hi Peter,

We added DMX search to site search and regularily encounter a strange error:
When (site-)searching for any string which is definitely in the DMX repository, randomly (but very often) get the error message "Conversion from type 'DBNull' to type 'Long' is not valid." in the search results page and no result shows up.

Searching in DMX works fine then.

I've investigated quite a lot on this and now I'm able to reproduce this error:
It only occurs when Folder sizes are not correct in DMX.

That leads to another issue: Our DMX randomly (from once a week to twice a day) drops all folder sizes (just an empty size colon in the Ajax GUI).
After running the script "reset folder sizes", site search is working perfectly again.

Any ideas on dropping folder sizes?
Or: is there a way to run this script from schedule?

Thanks!

-Chris

Hi Chris,

Can you verify the existence of 3 triggers on the table DMX_Entries and that they are enabled and running? It's the trigger that sets the field. If you add a new item LastModified and the size field should get set.

Peter

Hi Peter,

just checked twice - they're all present and active...

-Chris

Hi Chris,

It runs DMX_ResetFolderSizes PortalId, -1 during maintenance (twice per day by default). That should fix any errors in folder sizes, not create them.

Peter

Perfect, thanks!

I added this to SQL schedule on the server - so it'll run completely DNN-independant.
I figured out that it was the DMX maintainance task causing this quitting with a SQL timeout error.

I ran that SP manually (PortalId, EntryId 0) - the whole SP took more than 35 minutes on our server.

What else besides cleaning up temp dirs, purging logfiles and Checking Foldersizes does the Maintainance task do?

Could I probably automate this with standard Windows tasks for cleaning up the filesystem and SQL schedule tasks?

I'm a bit afraid to increase SQL timeout in the connection string just in case anything really goes wrong...

-Chris

Hi Chris,

The maintenance task does only what was mentioned. Nothing more. But of course this may change in the future. It is really meant to run twice a day for things that can be done unintrusively and are not immediately critical.

You could automate any maintenance bit any way you'd like. These procedures are meant to check and repair. The one thing to watch out for when doing massive swoops of the DMX db and making updates is the triggers. There are triggers on the DMX_Entries table. They are carefully designed to only fire when necessary. Typically they fire when you are making a change to a field that impacts the structure of DMX (i.e. the CollectionID, LastVersionID, FileSize etc fields). If you're doing your own SQL and updating any of these fields (check the trigger about the fields) you risk having a very long SQL update run as there will be a cascade of updates happening.

Peter