Archive for February, 2010

Report Viewer Control fails to render correctly in IE8

One of our more widely used application uses the Report Viewer Control to render SQL Server Reporting Services 2005 reports.

We are migrating to IE8 in the near future, so it was up to the various development teams to ensure compatibility. It should have been oh so easy :-)

Figure 1 shows the Report Viewer Control correctly rendering, a report is produced with twenty pages. Scrolling to the bottom of the control works as expected.

Figure 1- Application renders correctly in IE6

Figure 2 shows the same page and content in IE8. All looks good until you scroll to the bottom of the report (shown in Figure 3).

Figure 2 - All looks okay in IE8…. however….

Figure 3 - Scroll bar not rendered correctly [circled in red], page number footer missing (it is visible in Figure 1 when rendered in IE6)

There is a workaround for this particular issue. It involves the DOCTYPE markup that you may have in your master page or each individual page.

You can read more information about DOCTYPES at Holly Bergevin’s page: DOCTYPE at Community MX

Removing it completely from your page will make the browser work in ‘quirks’ mode. You’ll find that enabling ‘quirk’ mode will ensure the report is rendered correctly. See MSDN social.

If like me, you’ve got your DOCTYPE in your master page, and you’d really like to keep your XHTML compliant markup in place for the majority of your pages, it is a little more tricky. Either code the DOCTYPE in each page (removing it from your Master page! yuck!)… or find another workaround.

I search in vain for a solution. If you can help, please comment on this article. It seems it is a known bug!


Massive SharePoint config database log file

Its a common problem that many of us have. You set up your SharePoint farm, and its been running sweet as a nut, till you get asked one difficult question by the server team… why is the SharePoint configuration database log file so large?

SharePoint 2007 creates its databases in FULL RECOVERY mode. This is presumably because the SharePoint central administration pages were going to offer a more comprehensive recovery option, however I’ve only ever seen a full database restore. However, even though the built in GUI doesn’t make the use of the FULL RECOVERY model, I don’t think we should discount it.

There are two (nice) ways of coping with the log growth issue;

  1. You use your own backup strategy [NB this means you can’t use the built in restore option anymore], e.g. Scheduled SQL Job to backup the databases and logs yourself. When you do this, you have the option to use the WITH TRUNCATE ONLY option, or…
  2. Use the built in SharePoint backup/restore service from Central Admin, and schedule log truncations at defined intervals. (see below snippet of code shamelessly stolen from the Microsoft DBCC Shrink file tutorial)

– Example truncating a config db logfile to 70 MB):
BACKUP LOG [Sharepoint_Config] TO DISK=’drive:\path\Yourbackupfile.bak’
USE [SharePoint_Config]
DBCC SHRINKFILE (N’SharePoint_Config_log’ , 70)

– Note: the 70 is the 70MB.  

There is an excellent article on Death By Patterns website about log file management. This gives you an overview of why logs grow, and how they work in practice.

It should be noted that in more than a few places on the net, people recommend changing the database mode from FULL to SIMPLE in order to perform a DBCC SHRINKFILE. Whilst this is a simple and effective solution it takes away a crucial service that administrators can perform on a live SharePoint farm, if something goes wrong during the day, before a backup takes place, you have the capability of doing a in place transaction rollback.

See Sherin George’s blog for an excellent overview of the recovery models available in SQL Server.

See Server Fault discussion on SharePoint recovery models.


By SpittingCAML in SharePoint, T-SQL  .::. Read Comment (1)

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.