Display Alert on .Net Page After Postback

I have a C# page that is writing some records to a database when the user clicks a button. The user wanted a popup confirmation that the records were written successfully. So I added a HiddenField to the page and wrote some simple javascript to check the value of the HiddenField and display the value of the field if it’s not blank.

I added this to the ASPX page just after the <Form> tag:
<asp:HiddenField ID=”MsgTxt” runat=”server” Value=”” />
<script language=”javascript” type=”text/javascript”>
   var AlertMsg = document.getElementById(‘<%=MsgTxt.ClientID%>’).value;
    if (!AlertMsg == ”) {
        alert(AlertMsg);
    }
</script>

I added this to the button that writes the records to the database:
   MsgTxt.Value = “Message”;

I added this to the Page_Load to clear the variable so it’s only displayed once:
    if (Page.IsPostBack)
    {
        MsgTxt.Value = “”;
    }

That should do it. It’s a simple change to display any type of alert message after a postback.

Failed to get value of the “Approval Status”

The full error message reads “Failed to get value of the “Approval Status” column from the “Moderation Status” field type control”. This error has started occuring on document libraries containg web part pages that were upgraded from SPS 2003. The Hidden property on the Approval Status field has somehow been set to false. The Hidden property should be True.

I found this fix. Download a utility called SharePoint Manager 2007 from this site.
Run the application on a SharePoint server.
Go to View – Object Model and make sure “Full” is selected.
Browse to the library in the treeview.
Open the list of Fields and select the Approval Status field.
Change the Hidden property to True.
If the property is already set to True then change it to false and save it. Then change it back to True and save again.

Mass Deleting Document Version History

Version history takes a huge amount of disk space
The following SQL will delete the version history for a specific doc or set of docs
BE VERY CAREFUL! Remove the first line and run a SELECT statement first so you don’t delete the wrong versions!

Set the DirName = to the path to the doc library
Set the leafname = to the name of the file

delete from alldocversions
from alldocversions v inner join alldocstreams s on s.id = v.id
inner join alldocs d on d.id = s.id
where DirName = ‘FolderPath’ and leafname like ‘a%’

Here’s a cursor procedure to delete selected files

SET NOCOUNT ON
declare @dirname varchar(100)
declare @leafname varchar(255)

DECLARE complex_cursor CURSOR FOR
    select distinct DirName, LeafName
 from alldocversions v inner join alldocstreams s on s.id = v.id
 inner join alldocs d on d.id = s.id
 where DirName like ‘Folderpath%’ and leafname like ‘c%’;
OPEN complex_cursor;
FETCH NEXT FROM complex_cursor INTO @dirname, @leafname
WHILE @@FETCH_STATUS = 0
BEGIN
 PRINT ‘Deleting ‘ + @dirname + ‘, ‘ + @leafname

 DELETE FROM alldocversions
 FROM alldocversions v inner join alldocstreams s on s.id = v.id
 inner join alldocs d on d.id = s.id
 where DirName = @dirname and leafname = @leafname

 FETCH NEXT FROM complex_cursor INTO @dirname, @leafname
END
CLOSE complex_cursor;
DEALLOCATE complex_cursor;

SET NOCOUNT OFF

403 Forbidden and Forms Authentication with MOSS

We have a public MOSS site setup to use Forms Authentication for protected content. When the user hits files in certain document libraries, the user is automatically redirected to the login page and then returned to the document after a successful login. However, for some users, when they click a link to view a protected file they are not redirected to the login page and a “403 Forbidden” error message is displayed in Internet Explorer. This behavior does not occur in non-IE browsers (Firefox, Safari).

After some research I found this article. It looks like the culprit is a Microsoft add-in for Office Live.

Fix: Uninstall the application called “Microsoft Office Live Add-in 1.3”. That solved the problem right away. No system reboot or browser restart necessary…

Errors Uploading Files to SharePoint After SP1

We have 2 different MOSS farms (internal and external) and most of our users upload files ranging in size from under 1 MB to over 100 MB. In the past we had the typical SharePoint issues with users uploading large files when they were in remote locations with a slow upload speed.

We installed WSS and MOSS SP1 on our external farm first and immediately received reports of problems uploading files over 2 MB. About a month later we upgraded our internal farm to SP1 and, again, immediately had reports of problems uploading files.

After much digging and not seeing anyone else with this problem, I ran across a Microsoft KB article that eventually solved my problem. I tried several things before I found the magic fix.

So what’s the fix?
Modify the web.config in your SharePoint site to include the following:

Look for this line:
<httpRuntime maxRequestLength=51200 />

Change it to this
<httpRuntime executionTimeout=999999 maxRequestLength=51200 />

The Microsoft KB article is here

This small change fixed the problem on both of our farms.

SharePoint HTTP to HTTPS Redirection

The scenario is a MOSS site with HTTP and HTTPS enabled but you want all traffic to go to HTTPS. I thought this would be a fairly simple using IIS but apparently not…

Here’s a good description of the problem and fix

Basically you just change your public URL in Alternate Access Mappings to HTTPS.
Then you go to the properties on your site in IIS and change the TCP port to something other than port 80. I changed mine to port 8001.
Now create a new web site and select the same IP as your SharePoint site and enter the host name as the “host header”. (I’m not sure this is required or why it would be…)
Now go to the “Home Directory” tab of your new site on port 80 and select “A redirection to a URL” and enter the HTTPS address of the SharePoint site.
Now go to your SharePoint site using HTTPS and open the properties. Select the Directory Security tab and click Edit in the Secure Communications section. Check the “Require SSL” and “Require 128-bit encryption”.

You should now be able to go to any address on your site using HTTP and it will automatically forward the browser to the same address using HTTPS.