First of all, everything is stupid. That being said, I'm working on converting a set of FormFields in a Drop Down List (DVDropDownList) in a Custom List Form, and ran into the following problem:
Say a user makes selections in one of these custom drop-down lists, and then clicks OK, but the user is not allowed to continue (for example a validation error is found upon postback: a nonexistent user is given in a “people” field on the form)… in this case the drop-downs appear to remain selected but when the form is finally submitted, no data will be added to the list for these fields! The fields just end up lost, recorded as blank entries.
Furthermore, I discovered that any sort of postback preventing the user from moving forward causes the same problem.
The solution? Setting EnableViewState="false" on all of the Drop Down Lists seems to have done the trick. I'm not sure why it works, but maybe it has something do to with my alternate data source for the DDLs conflicting with the original field definitions in the list (which have no selections). Maybe I'll never know. Maybe I don't care.
Saturday, June 26, 2010
Selecting SQL collation for Windows Sharepoint Services 3.0
When pre-installing SQL 2005 database services and databases for use with Sharepoint, choose the correct collation the first time!
Database server collation should be set to "case-insensitive", and the database should be "case-insensitive", "accent-sensitive", "kana-sensitive", and "width-sensitive". Or, put in SQL 2005 terms, make sure you select "Latin1_General_CI_AS_KS_WS" when creating your WSS 3.0 databases. This also goes for the Search (WSS_Search_SERVERNAME) database.
More info: http://technet2.microsoft.com/windowsserver/WSS/en/library/58d28a34-7a84-4564-a4cb-0e6b5425f67e1033.mspx
--pup out
Database server collation should be set to "case-insensitive", and the database should be "case-insensitive", "accent-sensitive", "kana-sensitive", and "width-sensitive". Or, put in SQL 2005 terms, make sure you select "Latin1_General_CI_AS_KS_WS" when creating your WSS 3.0 databases. This also goes for the Search (WSS_Search_SERVERNAME) database.
More info: http://technet2.microsoft.com/windowsserver/WSS/en/library/58d28a34-7a84-4564-a4cb-0e6b5425f67e1033.mspx
--pup out
Dissecting Sharepoint 3.0: Invisible documents and the check-out process
The case of the missing Sharepoint documents: If you require document-check-out in your Sharepoint document library, uploads using Windows Explorer or the “Upload Multiple Documents” tool could have surprising results.
In the Sharepoint document library settings, you have the option to “require check out”. If you choose to “require documents to be checked out before they can be edited”, it is important to note the behavior of freshly uploaded documents.
With “require check out” enabled, only the owner (or person who uploaded the document) gets to see a document until it is actually checked in. Using the standard “Upload” button in the document library, users will be prompted to enter comments and then check in the document. However, anyone using the “Upload Multiple Documents” option (available if you have Microsoft Office 2003 or later installed on your machine), will never be asked if they would like to check the documents in (the same goes for uploading documents using Windows Explorer). As a result, the user may have successfully uploaded the documents to the site, but they all remain checked out. A document that has been uploaded but never checked in retains a ghostly and invisible status allowing it to be seen only by the owner.
Someone with Full Control of the document library (such as the site owner) can see a list of these phantom files by going to Shared Documents > Settings > Checked Out Files. Here one can find a list of all of the mysterious files that have never been checked in - (and are therefore invisible to others). If for some reason the original uploader isn’t available to check in the files, this tool can be used to take ownership of the files so that they may be checked in.
Tinkering under the hood:
In the content database for the site, you can see the behavior of checked out files behind the scenes. Looking at the SQL tables, here are some of the fields that can be of interest when investigating Sharepoint document issues:
The AllDocs Table:
- CheckoutUserId: ties to UserInfo table (tp_ID)
- CheckoutDate: Checkout Date (duh)
- Version: Internal version number
- UIVersionString: Display document version
- IsCurrentVersion: (1=yes, 0=no)
- Level: Checkout status of the file (1=checked in, 2=minor version,255=checked out)
The AllUserData Table: (more document versioning/history)
- tp_IsCurrent: When a file is checked out, tp_IsCurrent is set to false on that file’s record, and a new line is created for the checked-out version of the file (wherein tp_IsCurrent becomes true).
- tp_DirName: The parent directory or document library housing the file
- tp_LeafName: The name of the file
- tp_ContentType: In this case, “Document”
- nvarchar1: Username of the last person that modified the file
- nvarchar2: Username of the person that created the file
- nvarchar3: File extension
- tp_level: this indicates the checkout status of the file (1=checked in, 2=minor - version,255=checked out)
- tp_UIVersionString: Display document version
In the Sharepoint document library settings, you have the option to “require check out”. If you choose to “require documents to be checked out before they can be edited”, it is important to note the behavior of freshly uploaded documents.
With “require check out” enabled, only the owner (or person who uploaded the document) gets to see a document until it is actually checked in. Using the standard “Upload” button in the document library, users will be prompted to enter comments and then check in the document. However, anyone using the “Upload Multiple Documents” option (available if you have Microsoft Office 2003 or later installed on your machine), will never be asked if they would like to check the documents in (the same goes for uploading documents using Windows Explorer). As a result, the user may have successfully uploaded the documents to the site, but they all remain checked out. A document that has been uploaded but never checked in retains a ghostly and invisible status allowing it to be seen only by the owner.
Someone with Full Control of the document library (such as the site owner) can see a list of these phantom files by going to Shared Documents > Settings > Checked Out Files. Here one can find a list of all of the mysterious files that have never been checked in - (and are therefore invisible to others). If for some reason the original uploader isn’t available to check in the files, this tool can be used to take ownership of the files so that they may be checked in.
Tinkering under the hood:
In the content database for the site, you can see the behavior of checked out files behind the scenes. Looking at the SQL tables, here are some of the fields that can be of interest when investigating Sharepoint document issues:
The AllDocs Table:
- CheckoutUserId: ties to UserInfo table (tp_ID)
- CheckoutDate: Checkout Date (duh)
- Version: Internal version number
- UIVersionString: Display document version
- IsCurrentVersion: (1=yes, 0=no)
- Level: Checkout status of the file (1=checked in, 2=minor version,255=checked out)
The AllUserData Table: (more document versioning/history)
- tp_IsCurrent: When a file is checked out, tp_IsCurrent is set to false on that file’s record, and a new line is created for the checked-out version of the file (wherein tp_IsCurrent becomes true).
- tp_DirName: The parent directory or document library housing the file
- tp_LeafName: The name of the file
- tp_ContentType: In this case, “Document”
- nvarchar1: Username of the last person that modified the file
- nvarchar2: Username of the person that created the file
- nvarchar3: File extension
- tp_level: this indicates the checkout status of the file (1=checked in, 2=minor - version,255=checked out)
- tp_UIVersionString: Display document version
Process Info - NPSrvHost.exe
This little-known process has a simple explanation if you are a NetPro ChangeAudior or SecurityManager user...
NPSrvHost.exe is the NetPro Compliance Agent service process. It may or may not be using an interesting amount of memory (in my case, a fascinating amount of memory), but fear not, it is nothing foreign so long as you are a NetPro user.
More Info: http://netpro.com
NPSrvHost.exe is the NetPro Compliance Agent service process. It may or may not be using an interesting amount of memory (in my case, a fascinating amount of memory), but fear not, it is nothing foreign so long as you are a NetPro user.
More Info: http://netpro.com
Broken ASP.NET applications in Vista / IIS 7.0
When publishing an ASP.NET app to your IIS 7.0 server, HTTP 500.19 Error messages might indicate a broken IIS registration for the .NET Framework
Who doesn't love a good Internal Server Error? How about this beauty?
This error can spew forth if you're trying to publish your ASP.NET w/ AJAX application to IIS 7.0 and something is amiss with your .NET 2.0 (or possibly 3.0 or 3.5) registration in IIS.
It may be time to re-register the .NET framework in IIS with this command:
%windir%\Microsoft.NET\Framework\v(.NET VERSION HERE)\aspnet_regiis.exe -i
However, if you're in the mood to tinker, you can try editing the %windir%\System32\inetsrv\config\applicationHost.config file, where you'll find a line that reads:
Just change this to "Allow" if your error referred to the "" section in your web.config file.
Similarly, if the error was really about the "" section of the web.config, then look at changing this line to "Allow":
If things are truly not well with your .NET registration, then you might still see this kind of an error:
... and if that's the case, it's probably time to stop messing around under the hood and hope that the "aspnet_regiis.exe -i" command solves your problems. In Vista, .NET is tightly intertwined with the operating system, so reinstall attempts can result in tail-chasing and messages like "Error: Product already installed . . . This product is already installed as part of the operating system."
Who doesn't love a good Internal Server Error? How about this beauty?
| HTTP Error 500.19 - Internal Server Error | |
| The requested page cannot be accessed because the related configuration data for the page is invalid. | |
| Detailed Error Information | |
| Module | IIS Web Core |
| Notification | BeginRequest |
| Handler | Not yet determined |
| Error Code | 0x80070021 |
| Config Error | This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false". |
| Config File \\?\C:\inetpub\wwwroot\web.config | |
This error can spew forth if you're trying to publish your ASP.NET w/ AJAX application to IIS 7.0 and something is amiss with your .NET 2.0 (or possibly 3.0 or 3.5) registration in IIS.
It may be time to re-register the .NET framework in IIS with this command:
%windir%\Microsoft.NET\Framework\v(.NET VERSION HERE)\aspnet_regiis.exe -i
However, if you're in the mood to tinker, you can try editing the %windir%\System32\inetsrv\config\applicationHost.config file, where you'll find a line that reads:
Just change this to "Allow" if your error referred to the "
Similarly, if the error was really about the "
If things are truly not well with your .NET registration, then you might still see this kind of an error:
| HTTP Error 404.3 - Not Found | |
| The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map. | |
| Detailed Error Information | |
| Module | StaticFileModule |
| Notification | ExecuteRequestHandler |
| Handler | StaticFile |
| Error Code | 0x80070032 |
... and if that's the case, it's probably time to stop messing around under the hood and hope that the "aspnet_regiis.exe -i" command solves your problems. In Vista, .NET is tightly intertwined with the operating system, so reinstall attempts can result in tail-chasing and messages like "Error: Product already installed . . . This product is already installed as part of the operating system."
Phantom Web Parts in Sharepoint 3.0/2007
What can you do if you have uninstalled a web part, but it remains in your list of "All Web Parts"? Unable to delete a web part?
A failed installation or ungraceful removal of a web part from Sharepoint can result in a web part continuing to be available in the "All Web Parts" list, and yet not truly be installed or functioning. This could even prevent the proper re-installation of said web part until the cause of the tie-up is found.
First, check and make sure the web part has truly been uninstalled. Run stsadm.exe -o enumwppacks at the command line on your Sharepoint server for a list of currently installed web part .cab packages. (if you don't already have it handy, stsadm.exe can be found in the %windir%\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN directory).
For example, if you are having this problem with the KWizCom.ListMarquee web part (which was the case for me), you should see a .cab file like "listmarquee_deploy.cab" listed for your site. If you do, you should be able to use this command to remove it: stsadm.exe -o deletewppack -name -url .
If the .cab file related to the troublesome web part is not listed, then make your way into the virtual directory for your Sharepoint web, and look at the wpcatalog directory (\VirtualDirectories\\wpcatalog). If you see a .dwp file associated with the web part here, delete it. Now, make sure you're displaying hidden files and folders, and enter the wpcatalog\_vti_cnf directory. It is likely that you will find a .dwp file here for the lingering web part (in my example this would be, "KWizCom.ListMarquee_1.0.0.0__30fb4ddbec95ff8f_ListMarquee.dwp"). Go ahead and delete this file.
Hopefully this will clear up the sticky web part entry and either permit re-installation or allow everyone to go their separate ways.
A failed installation or ungraceful removal of a web part from Sharepoint can result in a web part continuing to be available in the "All Web Parts" list, and yet not truly be installed or functioning. This could even prevent the proper re-installation of said web part until the cause of the tie-up is found.
First, check and make sure the web part has truly been uninstalled. Run stsadm.exe -o enumwppacks at the command line on your Sharepoint server for a list of currently installed web part .cab packages. (if you don't already have it handy, stsadm.exe can be found in the %windir%\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN directory).
For example, if you are having this problem with the KWizCom.ListMarquee web part (which was the case for me), you should see a .cab file like "listmarquee_deploy.cab" listed for your site. If you do, you should be able to use this command to remove it: stsadm.exe -o deletewppack -name
If the .cab file related to the troublesome web part is not listed, then make your way into the virtual directory for your Sharepoint web, and look at the wpcatalog directory (
Hopefully this will clear up the sticky web part entry and either permit re-installation or allow everyone to go their separate ways.
Subscribe to:
Posts (Atom)