Now I know this is not a new subject and the solutions are out there. So I'm writing this (short this time) article as a basic summary of what I've come across.
So what's the problem?
Some of you must have come across this before. The Shared Service Provider's crawler get stuck and you can't stop it. It also does not add any new items to the index.
I've found two great articles that deal with this issue.
The first one by Mike Hanley explains how to resolve this issue with clear instructions and good screenshots. It can be found here.
The second is a support KB by Microsoft which expands what is explained in Mike's article by adding more tables which need fixing. It can be found here under KB930887.
Monday, 31 March 2008
Sunday, 10 February 2008
Datetime field bugs
Update 24/04/08 (Solved!) - There is an official hotfix available which resolves this issue. You'll have to request it from Microsoft but it's available here: http://support.microsoft.com/kb/948157.
Update 15/02/08 - Partial solution provided by Microsoft Support. As this is not exactly a supported fix, please contact me privately for details or leave a comment and I'll contact you.
CRM 4.0 coming out just at the turn of a year and customers going from 2007 to 2008 in various date fields raised an interesting bug.
The problem is with saving forms where I try to enter a date at the beginning of any year like 01/01/2008 I get the following error:
This error basically states "Invalid Argument" for the newly entered date value. Which is odd, as this is a real date.
Turning on the DevError flag produces the following output when I attempted to open anything saved with a "bad" datetime value. This was followed by a long stack trace.
This all struck me as being very odd. To try and narrow down the issue, I wanted to see if this only happens when moving between years or if it also arrises on the first day of any given month. I quickly attempted to enter a new date as the 01/02/2008 (first of feb) with different time values but they all worked. It appears the problems only happen when moving between years.
I'd just like to add that this happens with all date fields in the system. Default and custom entities with default or custom datetime fields. Any mix will do, all you need is a datetime field.
To sum up the results from my various checks, this problem only seems to happen when the value entered in any datetime field changes year values (ex. 2007 and 2008) when comparing the local time zone and the GMT time zone datetime values. This can be reproduced by entering a value on 01/01 of any year with a time value which is lower than your local GMT offset (ex. 01:30am for GMT+2 or 04:30am for GMT+5).
In addition, I have also performed the exact same tests on 3 different CRM 4.0 deployments in both clean installation and upgraded (from CRM 3.0) environments. They all performed in the exact same way.
Microsoft have provided me with an unsupported SQL script which temporarily fixes the issues described in this post. However, I would rather not make this fix publically available as it does involve directly editing the CRM databases.
A permenant hotfix will be made available for this matter shortly (I hope). I will post an update once this happens.
Update 15/02/08 - Partial solution provided by Microsoft Support. As this is not exactly a supported fix, please contact me privately for details or leave a comment and I'll contact you.
CRM 4.0 coming out just at the turn of a year and customers going from 2007 to 2008 in various date fields raised an interesting bug.
The problem is with saving forms where I try to enter a date at the beginning of any year like 01/01/2008 I get the following error:
This error basically states "Invalid Argument" for the newly entered date value. Which is odd, as this is a real date.
Turning on the DevError flag produces the following output when I attempted to open anything saved with a "bad" datetime value. This was followed by a long stack trace.
System.ArgumentOutOfRangeException: Specified argument was out of the range ofAfter studying this problem further, I came across an interesting behavior. I changed the datetime field so it would not just show the date but also the time values. I then started playing with the time values and attempting to save each time. This problem only arrose between 12:00am and 02:00am (02:00am was the first time value that allowed me to save). This seemed odd but then I remembered my user was configured to work in the GMT+2 time zone. I Then attempted this with the GMT+5 time zone and it behaved in the exact same way apart for it starting to work properly at 05:00am.
valid values.Parameter name: GetDaylightChanges actual year: 2007,
MinValue.Year: 2008, MaxValue.Year: 9999
This all struck me as being very odd. To try and narrow down the issue, I wanted to see if this only happens when moving between years or if it also arrises on the first day of any given month. I quickly attempted to enter a new date as the 01/02/2008 (first of feb) with different time values but they all worked. It appears the problems only happen when moving between years.
I'd just like to add that this happens with all date fields in the system. Default and custom entities with default or custom datetime fields. Any mix will do, all you need is a datetime field.
To sum up the results from my various checks, this problem only seems to happen when the value entered in any datetime field changes year values (ex. 2007 and 2008) when comparing the local time zone and the GMT time zone datetime values. This can be reproduced by entering a value on 01/01 of any year with a time value which is lower than your local GMT offset (ex. 01:30am for GMT+2 or 04:30am for GMT+5).
In addition, I have also performed the exact same tests on 3 different CRM 4.0 deployments in both clean installation and upgraded (from CRM 3.0) environments. They all performed in the exact same way.
Microsoft have provided me with an unsupported SQL script which temporarily fixes the issues described in this post. However, I would rather not make this fix publically available as it does involve directly editing the CRM databases.
A permenant hotfix will be made available for this matter shortly (I hope). I will post an update once this happens.
Sunday, 20 January 2008
CRM 4.0 language packs - some more
I've just come across an official Microsoft PowerPoint presentation which details the CRM 4.0 licensing model. I do not know the current NDA status of this presentation so I won't go into it too much.
However, an interesting part of this document is a list of all languages expected to be released during Q1 2008 as both base installations and language packs.
The list is as follows:
However, an interesting part of this document is a list of all languages expected to be released during Q1 2008 as both base installations and language packs.
The list is as follows:
- Arabic
- Brazilian Protuguese
- Chinese - Simplified
- Chinese - Traditional
- Chinese - Traditional (Hong Kong)
- Czech
- Danish
- Dutch
- English
- Finnish
- French
- German
- Greek
- Hebrew
- Hungarian
- Italian
- Japanese
- Korean
- Norwegian
- Polish
- Portuguese
- Russian
- Spanish
- Swedish
- Turkish
Subscribe to:
Posts (Atom)