I recently completed an upgrade on a site from v4.11.10 to v6.2.1. after that I upgraded to the latest CMS Import however when trying to view the saved import definitions most (not all) nodes are saying "Error during load, check the logfile for details The given key was not present in the dictionary".
I've checked the logs and there is nothing in there relating to this - any ideas?
Another customer had this as well. It turned out that it was related to the document types. When he opened them he got the same error. I think not all data types exists in the new environment?
It's not a new environment as such it was an upgrade so all original doctypes/datatypes etc should still be there in their original places. Unfortunately with nothing written to the logs it's like looking for a needle in a haystack as this is a pretty big site. Any ideas how your other customer tracked down the offending document type? Also not sure how that would prevent this node from opening though?
I agree that this could be better. Strange that nothing is written to the logs but what you would get is a callstack then.. The other dev inspected all document types and there were 1 or 2 that gave issues. Don't know how he solved it since I think he needed to update the document types in the database or something. But when the document type is correct again the error is also gone in the saved definition.
You only see a single line with the error or do you get a YSOD?
No YSOD just a single line with the message is written into the content pane. Will have to keep trawling through the site to see if I find anything amiss with the datatypes or document types.
Update: I think the reason there is nothing in the logs is possibly a separate issue I've just identified. The site is load balanced across 2 servers and both logs are empty so investigating that now. Hopefully if we can resolve that issue we can see more detail on the error.
Logging has been restored but the information wouldn't have been logged in the live environment as it is set to ERROR level only. I've replicated it on a staging server and now have the following log entry to go on:
2014-09-23 14:57:14,020 [45] INFO umbraco.BusinessLogic.Log - [Thread 47] Redirected log call (please use Umbraco.Core.Logging.LogHelper instead of umbraco.BusinessLogic.Log) | Type: Error | User: 0 | NodeId: -1 | Comment: Error during load System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.Collections.Generic.SortedDictionary`2.get_Item(TKey key)
at CMSImportLibrary.DataAdapters.DataAdapterFactory.GetDataSource(String dataAdapterAlias)
at CMSImport.Controls.ImportSteps.SelectDataSource.()
at CMSImport.Controls.CMSImport.(Int32 )
at CMSImport.Controls.CMSImport.OnPreRender(EventArgs e)
Does that help shed any further light on the problem?
That was the same error. It's failing internal in an Umbraco API when getting the info from document types. Did you already try to open document types in the browser?
Thought about the stracktrace and on a hunch reinstalled the RSS DataAdapter and that looks to be it - it was missing since the upgrade I think! Well, at least this might help someone else :)
Error during load, check the logfile for details The given key was not present in the dictionary
Hi Richard,
I recently completed an upgrade on a site from v4.11.10 to v6.2.1. after that I upgraded to the latest CMS Import however when trying to view the saved import definitions most (not all) nodes are saying "Error during load, check the logfile for details The given key was not present in the dictionary".
I've checked the logs and there is nothing in there relating to this - any ideas?
Thanks, Simon
Hi Simon,
Another customer had this as well. It turned out that it was related to the document types. When he opened them he got the same error. I think not all data types exists in the new environment?
Cheers,
Richard
It's not a new environment as such it was an upgrade so all original doctypes/datatypes etc should still be there in their original places. Unfortunately with nothing written to the logs it's like looking for a needle in a haystack as this is a pretty big site. Any ideas how your other customer tracked down the offending document type? Also not sure how that would prevent this node from opening though?
Thanks, Simon
Hi Simon,
I agree that this could be better. Strange that nothing is written to the logs but what you would get is a callstack then.. The other dev inspected all document types and there were 1 or 2 that gave issues. Don't know how he solved it since I think he needed to update the document types in the database or something. But when the document type is correct again the error is also gone in the saved definition.
You only see a single line with the error or do you get a YSOD?
Cheers,
Richard
No YSOD just a single line with the message is written into the content pane. Will have to keep trawling through the site to see if I find anything amiss with the datatypes or document types.
Simon
Update: I think the reason there is nothing in the logs is possibly a separate issue I've just identified. The site is load balanced across 2 servers and both logs are empty so investigating that now. Hopefully if we can resolve that issue we can see more detail on the error.
Simon
Hi Simon,
Yeah think so since that message should write to the log..
Logging has been restored but the information wouldn't have been logged in the live environment as it is set to ERROR level only. I've replicated it on a staging server and now have the following log entry to go on:
Does that help shed any further light on the problem?
Cheers, Simon
Hi Simon,
That was the same error. It's failing internal in an Umbraco API when getting the info from document types. Did you already try to open document types in the browser?
Cheers,
Richard
Thought about the stracktrace and on a hunch reinstalled the RSS DataAdapter and that looks to be it - it was missing since the upgrade I think! Well, at least this might help someone else :)
Thanks Richard.
Oh same error for a different problem wel, I hope the same. Will add this one to the list I need to fix...
It was this line which led me to think that it couldn't find the adapter for some reason because it is followed by the missing key exception.
Cheers for the help.
Simon
is working on a reply...