Invalid postback or callback argument when trying to add a Web part

Invalid postback or callback argument when trying to add a Web part

• thekaran

  Some more inputs related to problem :-

  The default.aspx page for the portal is experiencing these errors and seems to be corrupt.A site created beneath this portal works perfectly fine.Does anyone have idea how to restore the portal page to its previous settings

  I have no luck so far and this is driving me crazy

  
  
  

• Jianxing

  We solved the issue by resetting the default.aspx page as suggested in another post we found. I've summerized the steps below:

  Every aspx page for each area has a corresponding entry in the DOCS table of the SITE content database. By default, the content field for this document is null, and it is being generated from the portal templates. When you modify a SharePoint page the entire file is uploaded into the DOCS table.

  • Find the SiteId for the site having the problem in the dbo.Sites table in the WSS config database. The SiteId is a GUID. You can use the UrlPath field to determine the correct SiteId.
  • Run the following query on the WSS contents database “SELECT SiteId, DirName, LeafName, Content FROM Docs WHERE LeafName = 'default.aspx’” The result of this query will show all the default.aspx pages within SharePoint. You can use the SiteId and the DirName to determine which is the page giving the problem. This page will also show a Content field which is not NULL. Remember the value of the DirName field as <ProblemDir> for the next step.
  • Run the following update query on the WSS contents database to revert the default.aspx page to its default configuration (generated from the portal templates) “UPDATE Docs SET Content = NULL WHERE LeafName = 'default.aspx' AND DirName = '<ProblemDir>'”.
  • The end user needs to reconfig the page as it has been reset to it’s default configuration again.

  See also the original post found:

  http://groups.google.nl/group/microsoft.public.sharepoint.portalserver/browse_thread/thread/a587187f00be34ca/4c9d7a8f04fdb59e lnk=st&q=Sharepoint+default.aspx+docs+leafname&rnum=1&hl=nl#4c9d7a8f04fdb59e

  
  

• CharlieRomeo

  I used this fix and it didnt fully fix the problem. now the default.aspx page cannot be opened in Frontpage and Im not getting an error as to why.
  
  When I add a webpart using IE it doesnt do anything the page refreshes and the webpart isnt there. We restarted the server and then there ended up being 5 Announcements which indicated our failed attempts of adding the webpart had actually added them.
  
  I then tried to remove the extra Announcements and it wouldnt let me the only thing I could do was set the visible option off on the extras and now theres only one Announcement displaying however it has the number [1] on the title bar.
  
  How can I resolve this the default.aspx page needs changing. All sub sites and other pages within the site work fine. Its just this one page.
  
  Marcus
  
  
  

• dotNET Dev

  I am resurrecting this old thread because I am also having the same problem that Vishal_LogicaCMG was having.

  Thanks to another great board contributer named Andy_T I have now accessed my SharePoint databases and tried out the fix in this thread. It "fixed" my pages, however, it also removed the formatting (extra menu bars, etc.) that I had put in with FrontPage 2003.

  My question is can I "fix" my pages in the database but keep what I've done in FP03 While the page content is intact, using the fix resets my pages to their default look.

  
  

• Dietz

  Thanks that worked! You are simply great
  
  

• kamuixkotori

  It's there look carefully...
  
  It seems like Content is a reserved word hence the blue color.
  
  Try:
  
  SELECT SiteId, DirName, LeafName, [Content] FROM Docs WHERE LeafName = 'default.aspx'
  
  

• Captain007

  Philip,

  I'm not sure if this helps, but here is what I discovered about my initial problem:

  When you edit a SharePoint page in FrontPage sometime it severs that page's connection to the server. In other words, it takes the value in the LeafName column in the Docs table and assigns this insanely long hash value to it, overwriting the NULL value that was in there previously. This is fine, most of the time. That is, until you try to add some other web part and you get an error. So, when I want to add a web part to my formated and "broken" SharePoint page, I go into the database (I am using SQL Server) and I use the following queries:

  This query gets all the large hash values for the pages on my SharePoint site:

  SELECT DirName, Content

  FROM Docs

  WHERE LeafName = 'default.aspx' and content is not null

  Then, once I have that information, I run this query to reset the page's LeafName back to NULL:

  UPDATE Docs SET Content = NULL

  WHERE LeafName = 'default.aspx' AND DirName = 'test'

  Where it says 'test' I put in the DirName from the first query. When I run the UPDATE query it strips the formatting from that page and I can then go in and add whatever web parts I need to. Once I add the new web parts I go back into SQL Server and rerun the second query except I get the hash value for the page I just reset back to NULL (you can get that from the first query) and I put it in for the Content value of the second query (so instead of it saying Content = NULL, it will say Content = <ridiculously large hash value>).

  After I run that query, it puts the previous formatting back onto the page, and also keeps the web part(s) I just added.

  Anyway, I hope that gives you some illumination. We Philips have to stick together... especially those of us that spell our name with only one 'L'. ;-)

  
  

• yxrkt

  When running:"SELECT SiteId, DirName, LeafName, content FROM Docs WHERE LeafName = 'default.aspx'"

  It returns the error:

  Msg 207, Level 16, State 1, Line 1

  Invalid column name 'content'.

  I don't see a column called "Content" but I see everything else

  Do you know another way to null this...

  
  
  

• my_display_name

  I'll answer my own question. The "default.aspx" Content value does appear to be the same for each portal. When I changed the Content to NULL, I was able to add web parts. I then updated Content value back to the original value. The web parts I added remained, but I could no longer add web parts - again. After restoring the Content value, the TFS related quick launch links did return. What I should have done from the start is call MS to get the hotfix KB915746 (http://support.microsoft.com/kb/915746). It's a quick patch and resolved my issue.

  
  

• Ren&amp;#233; Titulaer

  Check the ASP.NET version in IIS for this application.

  It worked in my case.

  Regards

  Rajpreet

  
  
  

• SonuK

  Thanks Ilske,

  Setting content to null fixed the problem for me too.

  
  

• 70Hours

  This worked for me - the error is gone. However, the Quick Launch no longer has the Process Guidance and Reports links. The Documents links are still there. How do you get these back Is this content value fixed Perhaps I can copy it from another project
  
• Invalid postback or callback argument when trying to add a Web part