Yesterday, I had a very strange effect, and I still cannot explain how this happened. In an intranet protal, there are about 1100 files linked by the different Document Modules. For some reason, about the half of it did not work anymore - and there was no entry in DNN's Event Viewer, because it came to some ASP.Net runtime error.

Inspecting the installation, I found out three things:

First: All the files were there. (Thanks god!)

Second: In DNN's file manager, I found that all the rights of the folders containing the files with the non-working links were reset to Administrators only. None of the other roles were checked anymore. I changed these rights (which was not really much to do, as everywhere, users have View access) But still: the links did not work, even for administrators.

Third: The URL field in the documents table ("FileID=xx") had entries, that did not exist in the Files table. I found all the files there, but with another, much higer FileID. So, after restoring a backup file (to a local SQL server), I found that the FileID there were right, and so I could write a little program that updated the URL fields in the Documents table to point to the right files again (using "FileName" and "Folder" to compare the backed up Files table with the one in the production database). Now it works again.

What I am still looking for is an answer to the question: How could this happen?

Best wishes

Michael

Sebastian,

thanks for the information. Are there any other schedule jobs that do some kind of "damage" to the database's integrity? (Just to turn them all off ;-))

Best wishes
Michael

I had the same issue, and I'm very glad to have found out the problem. :-/

My quesiton is: if I do the manual syncing, will that also cause the document IDs to change? I can't afford to have this happen again, even if I'm the one that causes it....