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…

MOSS Search Indexer “Access is Denied”

Have a MOSS farm the a web front-end and a separate search indexer. After installing some patches the indexer started failing with an Access is Denied message. MOSS configures a dedicated index machine by adding an entry to the HOSTS file that points the MOSS sites to the indexer’s IP address. If you try to connect to your MOSS site on the Indexer’s desktop you will unable to connect.

The patches are KB960803 and KB963027. You can read the notes here.

Following the instructions for Method 1 in the article fixed the problem and indexer was able to access and index the content again. The fix is a small registry entry that allows local connections to other host names.

Blank Dialog Using Send To

You can setup a “Send To” destination for a library so that users can easily copy files and all of it’s properties to another library. Very handy if you have a lot custom columns on the document library.

When a user selects “Send To” and a predefined destination on a SharePoint document, the user is redirected to a page with the destination and if the author should be prompted to send out updates. When the user clicks OK, a dialog box pops up with no message.

We found that this issue was solved by having the user run Microsoft Office 2007 diagnostics. This utility appears to fix the problem.

BTW, Firefox doesn’t have this problem… 🙂