Some things you should know:
Japan/America and Europe use different TV systems (NTSC and PAL respectivelly). This matters, because video games must be adjusted for the different for the different formats. Because NTSC is a bigger market, games are usually adjusted for NTSC, and only a cheap PAL conversion is made, running in wrong speed (slower than it should) and with lower resolution (picture is letterboxed and "squeezed"). See comparison between NTSC and PAL here:
http://www.youtube.com/watch?v=ZmMXA7FpR_U
This was an issue all up until the PlayStation 2/GameCube/Xbox generation! For example, Final Fantasy X has a horrible PAL port (notice how the lipsynch is always good at the beginning of lines, but gets progressivelly worse the longer the conversation is...)
It is also an issue when playing Virtual Console/PSN games, see for example:
http://www.youtube.com/watch?v=T4gKOD4K088
So - which games should you play to get the best experience?
Portable consoles
Play anything, no difference in performance!
NES
Get an NTSC console and NTSC games. Most PAL games (with some exceptions) are horrible ports. A PAL console can easily be modified to be region free, but games will still run in the slower speed!
SNES
Get an NTSC console and NTSC games. Most PAL games (with some exceptions) are horrible ports. A converter can let you play most NTSC games on your PAL console - but the games will still run in the slower speed! If you're handy with a soldering iron, you could do this: http://www.gamesx.com/importmod/snes5060.htm - but remember that many games are "semi-ported" (for example, speed of music has been corrected but nothing more). Also, while the speed may be corrected for PAL games, you will still get a letterboxed and squashed video.
Nintendo GameCube
Sony PlayStation
Sony PlayStation 2
Get NTSC games, and any machine that can play NTSC games, if they run they will run properly (not including disc swap mods etc!) Many PAL games are bad ports.
Note that some NTSC PS2 games can even do 480p (as opposed to 480i)! This option is almost always removed in the PAL port.
Nintendo Wii
PAL ports of Wii games are fine. On Virtual Console, the "import" games are fine (including Final Fantasy VI and Super Mario RPG), they run in proper NTSC speed and resolution. Avoid all other games that can be purchased in the European VC store as they are the same shitty PAL ports as when they were originally released. Try to get games from a store in an NTSC region instead. TurboGraphx games found in the VC store are always fine, that console were built so that games did not have to be adjusted for NTSC/PAL!
Sony PlayStation 3
For physical PS1 and PS2 games, see above (get NTSC games). NTSC/PAL is no longer something to care about on PS3 games, and PS3 games are region free (all PS3 games works on all PS3 consoles). The PS1 games found in the european PlayStation Stores are bad ports. From any console you can, however, access any store, just lie about which country you live in, but NTSC PS1 games MAY not play on a PAL machine or vice versa (when launching it, you may get an "invalid video mode" message).
Notes:
- For consoles not listed, I don't know.
- There are no one NTSC region - Japanese NTSC consoles wont run north american NTSC games.
- Regardless of console, viewing NTSC signal may may require certain cables. Component and RGB has a higher probability of working with most TVs than the common composite and RF cables.
söndag 5 februari 2012
måndag 14 september 2009
Some tips for working with URLs in the SharePoint Object Model
Ok, so concistency is not one of the strenghts of the SharePoint OM.
Here's a couple of tips that might just save you from some headache...
1. SPListItem.Url does not make any sense
A typical value is "Lists/MyList/31_.000" where 31 is the list ID, and 000 somehow represents the version number. Of course, if you prepend the web URL and open this in a web browser, you get a 404. Great. If you want to send the user to the item display form, you need to get the name of the display form from the content type, and the item ID and build the URL manually.
2. Don't trust the documentation
The documentation has this to say about SPWeb.GetList(string):
public SPList GetList(string strUrl);
// Summary:
// Returns the list with the specified site-relative URL.
//
// Parameters:
// strUrl:
// A string that contains the site-relative URL for a list, for example, /Lists/Announcements.
//
// Returns:
// A Microsoft.SharePoint.SPList object representing the list.
Which is great, except it's completely wrong. The URL must be server relative or absolute - not site relative.
3. Be extremely careful not to mix up Absolute, Server, Site and Web Relative URLs
For a subweb of a site which is in the root web of a server, a site relative and a server relative URL are equal, which makes it easy to confuse them. If they are confused, the code will fail as soon as it tries to open a web under any site collection which is not in the root path of the server.
(Similar things can happen if a Site/Web relative or Server/Web relative URL is confused as well.)
Here's an example how not to do it, right out of one of the Microsoft assemblies using Reflector.
In one of the content database tables (regarding alerts), they've named two columns "siteUrl" and "webUrl". These names are confusing, most of all because siteUrl is not the siteUrl at all; the column contains only server URLs! Also, the values in "webUrl" are server relative.
Then, the developer of Microsoft.Office.Server.Search.Query.SearchAlertHandler.OnNotification in assembly Microsoft.Office.Server.Search, assumed that the "siteUrl" was the URL of the site (false), and that webUrl was a site relative URL (also false). S/he wrote these lines:
using (SPSite site = new SPSite(alertHandlerParams.siteUrl)){
SPWeb web = site.AllWebs[alertHandlerParams.webUrl];
// most of the code is here
}
(They forget to dispose that web, so the code is leaking memory, but that's not the main issue here.)
The SPWebCollection, most commonly returned by SPSite.AllWebs[] and SPWeb.GetSubwebsForCurrentUser(), has an indexer which accepts a site relative string. That makes sense, so ok.
But with webUrl actually being a server relative URL, that line will fail and throw an exception for any web whose parent site is not located in that the root of the server. It wont fail if the site is in the root of the server, because then a site relative and server relative web URL are the same.
Result?
Search-based alerts are completely broken for any web not being a subweb of the root site collection. They will inevitably fail with a "There is no web named ..." in the ULS log and no alerts will ever be sent. This bug exists in at least both SP1 and SP2 of MOSS 2007.
The lesson is of course that it is extremely important to always ensure if you are passing an absolute or a server, site or web relative URL, and make sure that matches what is expected!
By the way, Microsoft are aware of this issue, and they where already aware of it when I contacted them about it a couple of months ago. Appearantly, having all features in working order is not a high priority. :-(
PS. I mixed up site and server quite a few times myself just when writing this entry. I hope I got it right now though... :-)
4. URLs can change, so use other identifiers if possible
Web URLs are not static. For example, they can be changed by administrators. If possible, try not to handle any URL as something constant! That is, avoid specifying URLs in permanent configuration files, web part properties, etc. Whenever possible, use GUIDs or other static identifiers.
If you have the option to chose between for example a SiteRelative or a WebRelative url, use the one which is most general for your purpose. For specifying a list in the same web, for example, the web relative URL would be best, site relative URL second best, and so on. (Again, concider using other identifiers before resorting to URLs.)
Even worse of course is to use "Title" or "DisplayName" as identifiers, as they are even more likely to be changed in the future than the URL. Also, unlike any other identifier, they are never guaranteed to be unique!
5. Use SPUtility, SPUrlUtility, HttpUtility if you can
Don't re-invent the wheel! SPUtility, SPUrlUtility and HttpUtility contains several methods for common operations with URLs, such as concatenating and splitting a URL string. Feel free to check them out in Reflector to see what they do if it's a least bit unclear.
Here's a couple of tips that might just save you from some headache...
1. SPListItem.Url does not make any sense
A typical value is "Lists/MyList/31_.000" where 31 is the list ID, and 000 somehow represents the version number. Of course, if you prepend the web URL and open this in a web browser, you get a 404. Great. If you want to send the user to the item display form, you need to get the name of the display form from the content type, and the item ID and build the URL manually.
2. Don't trust the documentation
The documentation has this to say about SPWeb.GetList(string):
public SPList GetList(string strUrl);
// Summary:
// Returns the list with the specified site-relative URL.
//
// Parameters:
// strUrl:
// A string that contains the site-relative URL for a list, for example, /Lists/Announcements.
//
// Returns:
// A Microsoft.SharePoint.SPList object representing the list.
Which is great, except it's completely wrong. The URL must be server relative or absolute - not site relative.
3. Be extremely careful not to mix up Absolute, Server, Site and Web Relative URLs
For a subweb of a site which is in the root web of a server, a site relative and a server relative URL are equal, which makes it easy to confuse them. If they are confused, the code will fail as soon as it tries to open a web under any site collection which is not in the root path of the server.
(Similar things can happen if a Site/Web relative or Server/Web relative URL is confused as well.)
Here's an example how not to do it, right out of one of the Microsoft assemblies using Reflector.
In one of the content database tables (regarding alerts), they've named two columns "siteUrl" and "webUrl". These names are confusing, most of all because siteUrl is not the siteUrl at all; the column contains only server URLs! Also, the values in "webUrl" are server relative.
Then, the developer of Microsoft.Office.Server.Search.Query.SearchAlertHandler.OnNotification in assembly Microsoft.Office.Server.Search, assumed that the "siteUrl" was the URL of the site (false), and that webUrl was a site relative URL (also false). S/he wrote these lines:
using (SPSite site = new SPSite(alertHandlerParams.siteUrl)){
SPWeb web = site.AllWebs[alertHandlerParams.webUrl];
// most of the code is here
}
(They forget to dispose that web, so the code is leaking memory, but that's not the main issue here.)
The SPWebCollection, most commonly returned by SPSite.AllWebs[] and SPWeb.GetSubwebsForCurrentUser(), has an indexer which accepts a site relative string. That makes sense, so ok.
But with webUrl actually being a server relative URL, that line will fail and throw an exception for any web whose parent site is not located in that the root of the server. It wont fail if the site is in the root of the server, because then a site relative and server relative web URL are the same.
Result?
Search-based alerts are completely broken for any web not being a subweb of the root site collection. They will inevitably fail with a "There is no web named ..." in the ULS log and no alerts will ever be sent. This bug exists in at least both SP1 and SP2 of MOSS 2007.
The lesson is of course that it is extremely important to always ensure if you are passing an absolute or a server, site or web relative URL, and make sure that matches what is expected!
By the way, Microsoft are aware of this issue, and they where already aware of it when I contacted them about it a couple of months ago. Appearantly, having all features in working order is not a high priority. :-(
PS. I mixed up site and server quite a few times myself just when writing this entry. I hope I got it right now though... :-)
4. URLs can change, so use other identifiers if possible
Web URLs are not static. For example, they can be changed by administrators. If possible, try not to handle any URL as something constant! That is, avoid specifying URLs in permanent configuration files, web part properties, etc. Whenever possible, use GUIDs or other static identifiers.
If you have the option to chose between for example a SiteRelative or a WebRelative url, use the one which is most general for your purpose. For specifying a list in the same web, for example, the web relative URL would be best, site relative URL second best, and so on. (Again, concider using other identifiers before resorting to URLs.)
Even worse of course is to use "Title" or "DisplayName" as identifiers, as they are even more likely to be changed in the future than the URL. Also, unlike any other identifier, they are never guaranteed to be unique!
5. Use SPUtility, SPUrlUtility, HttpUtility if you can
Don't re-invent the wheel! SPUtility, SPUrlUtility and HttpUtility contains several methods for common operations with URLs, such as concatenating and splitting a URL string. Feel free to check them out in Reflector to see what they do if it's a least bit unclear.
torsdag 3 september 2009
A random WSS 3.0 SP2 issue
I found this by accident:
http://support.microsoft.com/?id=909455
"Document library event handlers that use object model code without explicit impersonation fail with the "Cannot complete this action" error message after Windows SharePoint Services Service Pack 2 is installed"
"All document library event handlers must perform explicit impersonation to use Windows SharePoint Services object model calls."
"This behavior is by design."
I'll just leave it at that...
http://support.microsoft.com/?id=909455
"Document library event handlers that use object model code without explicit impersonation fail with the "Cannot complete this action" error message after Windows SharePoint Services Service Pack 2 is installed"
"All document library event handlers must perform explicit impersonation to use Windows SharePoint Services object model calls."
"This behavior is by design."
I'll just leave it at that...
torsdag 27 augusti 2009
A little bit about SPListItemCollection...
Don't:
SPList list = SPContext.Current.Web.Lists["MyList"];
SPListItem item = list.Items.GetItemById(7);
SPListItem item = list.Items.GetItemById(7);
Do:
SPList list = SPContext.Current.Web.Lists["MyList"];
SPListItem item = list.GetItemById(7);
SPListItem item = list.GetItemById(7);
Why?
Using the "Items" field of an SPList will always create an SPListItemCollection and populate it with all items from the database, which can take a long time if the list contains many items.
Calling GetItemById() directly on the SPList does not require this and can finish in a fraction of the time, even for a list with thousands of items.
To go further into this...
If performance is important (or if you are working with lists with many items), you should (or even must) avoid the "Items" field of SPList completely. Instead use SPQuery and SPList.GetItems(SPQuery) to create your own SPListItemCollection, and limit its size by setting these fields on the SPQuery:
- "ViewFields" - specify only the fields you need.
- Row Limit - set the maximum number of items you need
- Query - of course, to make the collection only contain items which you need.
- "ViewFields" - specify only the fields you need.
- Row Limit - set the maximum number of items you need
- Query - of course, to make the collection only contain items which you need.
For example,
Don't:
SPListItem item = list.Items.Add(...);
item.Update();
item.Update();
Do:
SPListItem item = list.GetItems(new SPQuery { RowLimit = 0 }).Add(...);
item.Update();
item.Update();
Another example,
Don't:
itemCount = list.Items.Count;
Do:
itemCount = list.GetItems(new SPQquery { ViewFields = "" }) .Count;
Much of this is usually not required of course, but for lists which contains hundreds of items the difference will likely be noticable.
By the way, many of the OM methods use SPQuerys "behind the curtain". For example, SPList.GetItemById() creates an SPQuery with RowLimit = 1 and a "where eq
Hope this is of use to anyone!
onsdag 3 december 2008
Firefox, Safari, SharePoint and modal windows
Ok, I've been taking a closer look at the problem with SharePoint, modal windows, Firefox and Safari.
Turns out the problem is NOT Firefox/Safari, rather, it is an issue with the setModalDialogObjectReturnValue() function in core.js. Basically, because of differences between Firefox/Safari and Internet Explorer, the result of the 'if' clause in this method is different. For Firefox/Safari, this has the result that the wrong method is used to set the return value of the window.
Here is a very quick and dirty workaround that works in FF3, Safari 3 and IE7 (and WSS 3.0 SP1/MOSS 2007 SP1).
Add the bold line to ...\12\TEMPLATE\LAYOUTS\1033\CORE.JS:
function setModalDialogReturnValue(wnd, returnValue)
{
if (wnd.opener !=null &&
typeof(returnValue)=='string' &&
wnd.opener.document.getElementById('__spPickerHasReturnValue') !=null &&
wnd.opener.document.getElementById('__spPickerReturnValueHolder') !=null)
{
wnd.opener.document.getElementById('__spPickerHasReturnValue').value='1';
wnd.opener.document.getElementById('__spPickerReturnValueHolder').value=returnValue;
wnd.returnValue=returnValue;
}
else
{
setModalDialogObjectReturnValue(wnd, returnValue);
}
}
I put this here only to illustrate the problem and the solution. I have not tested this with older browsers - this code will probably break functionality with older browsers! Preferably, one should modify the 'if' clauses in this method. Also, mind that changes to this file is not supported by Microsoft. It might be overwritten by future Service Packs or upgrades, so you better hope that this bug is fixed in the next Service Pack, or somehow put this fix in some other file.
So who is to blaim? Who should fix it?
What Mozilla changed to make this problem arise in Firefox 3 was simply to add support for the IE specific method showModalDialog(). They didn't have to - they already had another way to do the exact same thing.
For Firefox 3/Safari 3, the JavaScripts in core.js now choose the "IE" method to open the window, the "Firefox" method to set the return value to the window, and then again the "IE" method to read the return value from the window. Hence, the return value will always be undefined or null. The JavaScript functions must be modified in some way so that they are concistent.
No one is to "blaim" - Firefox and Safari supports everything IE supports, and Microsoft made an effort to support Firefox in SharePoint, but even though SharePoint worked in all browsers available during its release, it now fails to properly detect modern browsers.
While it's possible to work around the problem, and it should be quite easy to make the fix as a custom SharePoint solution, I recommend anyone being troubled by this issue to open a support case with Microsoft.
Turns out the problem is NOT Firefox/Safari, rather, it is an issue with the setModalDialogObjectReturnValue() function in core.js. Basically, because of differences between Firefox/Safari and Internet Explorer, the result of the 'if' clause in this method is different. For Firefox/Safari, this has the result that the wrong method is used to set the return value of the window.
Here is a very quick and dirty workaround that works in FF3, Safari 3 and IE7 (and WSS 3.0 SP1/MOSS 2007 SP1).
Add the bold line to ...\12\TEMPLATE\LAYOUTS\1033\CORE.JS:
function setModalDialogReturnValue(wnd, returnValue)
{
if (wnd.opener !=null &&
typeof(returnValue)=='string' &&
wnd.opener.document.getElementById('__spPickerHasReturnValue') !=null &&
wnd.opener.document.getElementById('__spPickerReturnValueHolder') !=null)
{
wnd.opener.document.getElementById('__spPickerHasReturnValue').value='1';
wnd.opener.document.getElementById('__spPickerReturnValueHolder').value=returnValue;
wnd.returnValue=returnValue;
}
else
{
setModalDialogObjectReturnValue(wnd, returnValue);
}
}
I put this here only to illustrate the problem and the solution. I have not tested this with older browsers - this code will probably break functionality with older browsers! Preferably, one should modify the 'if' clauses in this method. Also, mind that changes to this file is not supported by Microsoft. It might be overwritten by future Service Packs or upgrades, so you better hope that this bug is fixed in the next Service Pack, or somehow put this fix in some other file.
So who is to blaim? Who should fix it?
What Mozilla changed to make this problem arise in Firefox 3 was simply to add support for the IE specific method showModalDialog(). They didn't have to - they already had another way to do the exact same thing.
For Firefox 3/Safari 3, the JavaScripts in core.js now choose the "IE" method to open the window, the "Firefox" method to set the return value to the window, and then again the "IE" method to read the return value from the window. Hence, the return value will always be undefined or null. The JavaScript functions must be modified in some way so that they are concistent.
No one is to "blaim" - Firefox and Safari supports everything IE supports, and Microsoft made an effort to support Firefox in SharePoint, but even though SharePoint worked in all browsers available during its release, it now fails to properly detect modern browsers.
While it's possible to work around the problem, and it should be quite easy to make the fix as a custom SharePoint solution, I recommend anyone being troubled by this issue to open a support case with Microsoft.
tisdag 2 december 2008
Firefox vs SharePoint
One annoying thing when accessing SharePoint sites with Firefox is that it always requires the user to enter credentials when using NTLM authentication. It turns out, that's not a limitation, that is by design... Read this post by Patrick Cauldwell about how to make Firefox log in automatically to SharePoint sites.
Also, there's an issue in Firefox (and Safari) which disables most things which depend on popup windows, most notably, it's not possible to add web parts to a page.
Taking a look at the core.jss file, it appears that Microsoft put a fair bit of work into making this work in more than just IE, so it actually might be a bug in Firefox, not just Microsoft ignoring FF as I first thought. How about putting a vote for Bugzilla@Mozilla - Bug 463889 - Can't add web parts in Sharepoint 3 and MOSS 2007?
Also, there's an issue in Firefox (and Safari) which disables most things which depend on popup windows, most notably, it's not possible to add web parts to a page.
Taking a look at the core.jss file, it appears that Microsoft put a fair bit of work into making this work in more than just IE, so it actually might be a bug in Firefox, not just Microsoft ignoring FF as I first thought. How about putting a vote for Bugzilla@Mozilla - Bug 463889 - Can't add web parts in Sharepoint 3 and MOSS 2007?
måndag 1 december 2008
Jan vs Microsoft Content Management Server 2002
My first post - and it's a REALLY REALLY long one!
I've recently had to deal with a configuration of Microsoft Content Management Server 2002 which had been moved around and upgraded over the years. Some of the problems I ran unto were fairly unusual and finding solutions to some of the problems were difficult at best. Here are those problems and the solutions that worked for me. If you run into any problems with CMS, you should first check out the following two pages:
Site Deployment FAQ
HOW TO: Troubleshoot Site Deployment Issues in Microsoft Content Management Server 2002
Unable to export data from a CMS site.
- Everything else, including imports, worked fine.
- CMS 2002 with SP2, upgraded from SP1a, running SQL Server 2005, upgraded from SQL Server 2000
- The export fails after almost exactly 30 seconds (stuck on 0% or 5%), then fails.
- The error details would specify "403 (Forbidden)".
- Using a packet sniffer like Fiddler would reveal the complete 403 reason to be Directory Listing Denied.
- The 403 is pretty irrelevant: If doing an export preview, the real error is revealed to originate from .Net SqlClient Data Provider, and have the description Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
- The pages linked to above offers a lot of suggestions, non of which helped us.
Solution: Install hotfix 913401:
FIX: If you try to perform a site deployment export operation to SQL Server 2005, the export operation fails in Content Management Server 2002 Service Pack 2
How to install the hotfix:
1. Make a backup of the CMS database!
2. Request it from the page above. (If you can't, see below.)
3. Download it, extract it using the password in the e-mail.
4. Copy _both_ files to the folder "(MCMS)\Setup Files\SQL Install". Make a backup of "_dca.ini" first.
5. Run the DCA. Re-select the database. When continuing, the DCA should ask you to confirm the database upgrade.
6. Done!
Thanks to:
David Longnecker
Stefan Gossner
Unable to view or request hotfix on support.microsoft.com
Not really an CMS issue, but when clicking the "View and request hotfix downloads" link on the hotfix page above, you get a page with no content.
Solution: Turns out Microsoft's support site isn't very well localized. It tries to show a localized (in my case a Swedish) version of the page, which doesn't exist. Click the link in the top right corner, above the search bar, to change your location to USA.
Unable to install or upgrade all components because they require "Microsoft Java VM", "Visual J#.NET redistributable 3.0", or doesn't detect your version of Visual Studio.
Solution: Here's the steps I've found necessary to safely install CMS SP2... Surely, lots can go wrong with this old system so it's of course not complete. It's probably not a bad idea to reboot between every step.
1. Install the original version, without SP:s. Check only the core Server component.
2. You need to uninstall the .Net framework 3.0/3.5, or Site Manager will not be available. (If you don't need the Site Manager, you can skip this step.) You can re-install the 3.0/3.5 framework afterwards, however, all this takes time, and you might break other things installed on the computer. There is a faster workaround - quoting Alan McBee:
This is a RegEdit thing, so the usual Warning About Tampering With The Registry apply/
In RegEdit, go to this key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\
Rename the subkey v3.0 to something else -- I used XXXv3.0XXX.
In fact, I myself had to use this method, because uninstalling the framework still left that 3.0 key, so the Site Manager option was still disabled in the SP1a installation wizard.
3. Install SP1a. If you need them, install the Site Manager, Site Stager and the Dev tools now.
4. Change back the 3.0 registry key or re-install the .Net framework 3.0/3.5 (if you want it).
5. Install SP2.
6. Check Microsoft Update. There should be one single update from CMS available on Microsoft Update (under the "Office" category, I think). It is described as a security update, but you MUST get it if you are going to use SQL Server 2005, otherwise you wont be able to select the database in the DCA.
7. Install the hotfix mentioned above, if you are going to use SQL Server 2005 and if you are going to use a database from SQL Server 2000.
8. Create two websites in IIS, and create a new database (or copy an existing). Set up the security configurations, all the accounts and that boring stuff, and run the DCA/SCA.
9. If upgrading database from SP1a, make sure any custom built form still works (see below)
10. Done!
Thanks to:
Alan McBee
Stefan
Unable to select SQL Server 2005 database in the DCA
Problem: Authentication errors and other errors when choosing a DB in DCA.
Solution: For CMS to support SQL Server 2005, CMS 2002 SP2 must be installed, AND an update must be installed from Microsoft Update! Check update.microsoft.com. There should be one single update from CMS available on Microsoft Update (under the "Office" category, I think). It is described as a security update, but you MUST get it if you are going to use SQL Server 2005.
Custom forms are broken after SP1a upgrade to SP2
Problem: After upgrading CMS 2002 SP1a to SP2, custom built forms are broken. They may refer to an invalid URL, giving the user a 404 when submitting a form. CMS is using ASP.NET.
Solution: This is because they introduced a bug in a JavaScript in SP2. First, the post-SP2 hotfix package MIGHT fix this, but only try this if your environment is "expendable", or if you manage to find more documentation than I did... Or possibly, there might be a fix available for ASP.NET.
Otherwise, you can do what we did - it's insanely ugly, but it works. Copy this little piece of code somewhere into all templates containing broken forms:
<script language=”javascript” type="text/javascript">
<!--
// hack to fix MCMS2002 SP2/ASP.NET generated action target
__CMS_PostbackForm.action = __CMS_CurrentUrl;
// -->
</script>
Basically, this line is for some reason not generated in the HTML output by CMS SP2, but it was in SP1a. So far we've seen no side effects from adding this snippet, please let me know if you do.
I hope any of this is helpful to anyone else! (I really mean that, otherwise I've wasted a lot of time writing this...)
I've recently had to deal with a configuration of Microsoft Content Management Server 2002 which had been moved around and upgraded over the years. Some of the problems I ran unto were fairly unusual and finding solutions to some of the problems were difficult at best. Here are those problems and the solutions that worked for me. If you run into any problems with CMS, you should first check out the following two pages:
Site Deployment FAQ
HOW TO: Troubleshoot Site Deployment Issues in Microsoft Content Management Server 2002
Unable to export data from a CMS site.
- Everything else, including imports, worked fine.
- CMS 2002 with SP2, upgraded from SP1a, running SQL Server 2005, upgraded from SQL Server 2000
- The export fails after almost exactly 30 seconds (stuck on 0% or 5%), then fails.
- The error details would specify "403 (Forbidden)".
- Using a packet sniffer like Fiddler would reveal the complete 403 reason to be Directory Listing Denied.
- The 403 is pretty irrelevant: If doing an export preview, the real error is revealed to originate from .Net SqlClient Data Provider, and have the description Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
- The pages linked to above offers a lot of suggestions, non of which helped us.
Solution: Install hotfix 913401:
FIX: If you try to perform a site deployment export operation to SQL Server 2005, the export operation fails in Content Management Server 2002 Service Pack 2
How to install the hotfix:
1. Make a backup of the CMS database!
2. Request it from the page above. (If you can't, see below.)
3. Download it, extract it using the password in the e-mail.
4. Copy _both_ files to the folder "(MCMS)\Setup Files\SQL Install". Make a backup of "_dca.ini" first.
5. Run the DCA. Re-select the database. When continuing, the DCA should ask you to confirm the database upgrade.
6. Done!
Thanks to:
David Longnecker
Stefan Gossner
Unable to view or request hotfix on support.microsoft.com
Not really an CMS issue, but when clicking the "View and request hotfix downloads" link on the hotfix page above, you get a page with no content.
Solution: Turns out Microsoft's support site isn't very well localized. It tries to show a localized (in my case a Swedish) version of the page, which doesn't exist. Click the link in the top right corner, above the search bar, to change your location to USA.
Unable to install or upgrade all components because they require "Microsoft Java VM", "Visual J#.NET redistributable 3.0", or doesn't detect your version of Visual Studio.
Solution: Here's the steps I've found necessary to safely install CMS SP2... Surely, lots can go wrong with this old system so it's of course not complete. It's probably not a bad idea to reboot between every step.
1. Install the original version, without SP:s. Check only the core Server component.
2. You need to uninstall the .Net framework 3.0/3.5, or Site Manager will not be available. (If you don't need the Site Manager, you can skip this step.) You can re-install the 3.0/3.5 framework afterwards, however, all this takes time, and you might break other things installed on the computer. There is a faster workaround - quoting Alan McBee:
This is a RegEdit thing, so the usual Warning About Tampering With The Registry apply/
In RegEdit, go to this key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\
Rename the subkey v3.0 to something else -- I used XXXv3.0XXX.
In fact, I myself had to use this method, because uninstalling the framework still left that 3.0 key, so the Site Manager option was still disabled in the SP1a installation wizard.
3. Install SP1a. If you need them, install the Site Manager, Site Stager and the Dev tools now.
4. Change back the 3.0 registry key or re-install the .Net framework 3.0/3.5 (if you want it).
5. Install SP2.
6. Check Microsoft Update. There should be one single update from CMS available on Microsoft Update (under the "Office" category, I think). It is described as a security update, but you MUST get it if you are going to use SQL Server 2005, otherwise you wont be able to select the database in the DCA.
7. Install the hotfix mentioned above, if you are going to use SQL Server 2005 and if you are going to use a database from SQL Server 2000.
8. Create two websites in IIS, and create a new database (or copy an existing). Set up the security configurations, all the accounts and that boring stuff, and run the DCA/SCA.
9. If upgrading database from SP1a, make sure any custom built form still works (see below)
10. Done!
Thanks to:
Alan McBee
Stefan
Unable to select SQL Server 2005 database in the DCA
Problem: Authentication errors and other errors when choosing a DB in DCA.
Solution: For CMS to support SQL Server 2005, CMS 2002 SP2 must be installed, AND an update must be installed from Microsoft Update! Check update.microsoft.com. There should be one single update from CMS available on Microsoft Update (under the "Office" category, I think). It is described as a security update, but you MUST get it if you are going to use SQL Server 2005.
Custom forms are broken after SP1a upgrade to SP2
Problem: After upgrading CMS 2002 SP1a to SP2, custom built forms are broken. They may refer to an invalid URL, giving the user a 404 when submitting a form. CMS is using ASP.NET.
Solution: This is because they introduced a bug in a JavaScript in SP2. First, the post-SP2 hotfix package MIGHT fix this, but only try this if your environment is "expendable", or if you manage to find more documentation than I did... Or possibly, there might be a fix available for ASP.NET.
Otherwise, you can do what we did - it's insanely ugly, but it works. Copy this little piece of code somewhere into all templates containing broken forms:
<script language=”javascript” type="text/javascript">
<!--
// hack to fix MCMS2002 SP2/ASP.NET generated action target
__CMS_PostbackForm.action = __CMS_CurrentUrl;
// -->
</script>
Basically, this line is for some reason not generated in the HTML output by CMS SP2, but it was in SP1a. So far we've seen no side effects from adding this snippet, please let me know if you do.
I hope any of this is helpful to anyone else! (I really mean that, otherwise I've wasted a lot of time writing this...)
Prenumerera på:
Inlägg (Atom)