Sometimes our users make the mistake of restoring the wrong version of SQL Server to their database add-on.  It’s really an honest mistake to overlook, especially if you’re a developer who works with different versions of SQL Server and is rushed for time.

The hard part for us as support staff is to decipher what the error message trapped actually means.  Here’s the general error that is thrown when there is a mismatch in SQL Server version:

“The media family on device ‘Path to database file’ is incorrectly formed. SQL Server cannot process this media family.“

Not really indicative of the actual problem, is it?  I’ve included a table which shows when this error is thrown:

An exception to this rule is when you try to restore a SQL Server 2008 R2 database to SQL Server 2008.  This is the error thrown which is definitely a better message:

“The database was backed up on a server running version 10.50.1617. That version is incompatible with this server, which is running version 10.00.5828. Either restore the database on a server that supports the backup, or use a backup that is compatible with this server.”

Generally speaking, SQL Server databases are forward compatible (i.e. you can restore a lower version to a higher version) without any problems with the exception of SQL Server 2000.  You cannot restore a SQL Server 2000 database directly to SQL Server 2012. It will throw this error:

“The database was backed up on a server running version 8.00.2305. That version is incompatible with this server, which is running version 11.00.3339. Either restore the database on a server that supports the backup, or use a backup that is compatible with this server.”

To restore a SQL Server 2000 database to SQL Server 2012, you will need to perform a 2 step process.  You will need to restore it to SQL Server 2005, 2008, or SQL 2008 R2 first and then perform a backup.  From that backup, you can restore it to SQL Server 2012.

You can always find out what version number of SQL Server that you are running by executing this T-SQL statement in SQL Server Management Studio:

SELECT @@VERSION

Or there are nifty tables around the Internet which you can reference:

http://blog.sqlauthority.com/2013/01/18/sql-server-a-list-of-various-sql-server-rtm-and-service-pack-number/
http://sqlserverbuilds.blogspot.com/
http://www.sqlteam.com/article/sql-server-versions

Now, if you want to restore a database from a higher version to a lower version, you can do so by generating a script.  I won’t provide a step-by-step walk-through here as there are already many great guides on how to do this on the Internet:

http://www.mssqltips.com/sqlservertip/2810/how-to-migrate-a-sql-server-database-to-a-lower-version/
http://www.sqlserverblogforum.com/2011/05/restoring-a-database-from-higher-version-to-lower-version-sql-server/
http://blog.sqlauthority.com/2012/12/25/sql-server-restoring-2012-database-to-2008-or-2005-version-and-2-other-most-asked-questions/

When people want to start incorporating e-commerce activities in their site, they must be PCI compliant to do so.  There are many different companies/organizations out there that can help you determine if your web site is PCI compliant.

Many criteria must be met to be PCI compliant.  One of those criteria is to setup a custom error page.  Custom error pages are important because it hides the true error your application may display. The true error messages can be used to dissect and infer the back end design and structure of your web application.  Information that can be used to find weaknesses and exploit your web application.

In IIS, there are two types of custom error handling that you can and will need to set on your site. One is the traditional IIS custom error that is normally processed on the IIS level. The other is the ASP.Net custom error handling that is processed on the ASP.Net application level.  ASP.Net custom error handling is a bit tricky due to how it is processed through the handlers and depending on where it bombs out, can ultimately determine whether your ASP.Net custom error triggers.

In most cases setting up your ASP.Net custom error handling is straightforward. To achieve this, you simply add the “customErrors” element to your application’s web.config file.  The main attribute you will need to ensure is the “mode” attribute within the “customErrors” element.  You have three distinct choices.  They are “On”, “Off”, or “RemotelyOnly”.  You want to set it either for “On” or “RemoteOnly”.

Now here’s a caveat to being PCI compliant, some services will scan your site and test specific conditions to determine whether you have custom error handling enabled.  And one of the conditions they may throw at your application is passing a value/URL to your site that is similar to :

https://www.domain.com/[fakefile]?aspxerrorpath=/

which will not display your custom error page. However if you call a file that you know does not exist in your site:

https://www.domain.com/[fakefile]

you will find that your custom error page is displayed.

Confusing? Take a short breather and let me quickly explain.

Your ASP.Net custom error handling does work and the reaction your site invokes when someone calls on your site with the condition of “/[fakefile]?aspxerrorpath=/” is actually by design from Microsoft.  This condition in the URL request will stop the process from reaching the custom error handler thus bombing out before it can display your custom error page.

So what’s the solution?  The only work around that we can find is to setup a RequestFiltering rule to filter out the string “/[fakefile]?aspxerrorpath=/” from the URL string being called to your site.

In your web.config file input this code in your RequestFiltering element.


<requestFiltering>
 <denyQueryStringSequences>
 <add pre="" sequence="<span class=" hiddenspellerror="">aspxerrorpath=" />
 </denyQueryStringSequences>
 </requestFiltering>

Another way to implement this rule is through the IIS 7 or IIS 8 Manager using the RequestFiltering module and  setup the rule under the Query Strings tab with the query string “aspxerrorpath= “ set to Deny.

This will block the URL string “/[fakefile]?aspxerrorpath=/” whereby forcing it to call upon the file directly.

I already provided some reasons why you see this error in the Control Panel in a previous blog post:

so I won’t bore you with the details again.  Instead, I will be covering another error that is thrown and trapped on the back end:

“MODIFY FILE failed. Size is greater than MAXSIZE.”

Your database add-on space is capped depending on the type of database you ordered and how much extra disk space you purchased.  You can view the maximum size of your database using the tools in the DiscountASP.NET Control Panel by clicking on the MS SQL Manager link under the Database Management section in the menu to your left:

Your transaction log disk space is also capped at 1000 MB (1 GB).  Below are instructions on how to create and fix the problem.

How You Can Create the Problem

As in my last tutorial, I will be using the AdventureWorks database in this example.  First, I’ll attach both the database and log file to my local SQL Server instance.

Next, right click on the database and select Properties.  Go to the Files section and notice the initial size.

Go ahead and change these values to 500 and 1500, respectively, and click on OK.

Backup the database, upload it and try to restore it using the tools in the DiscountASP.NET Control Panel.  A base SQL Server 2005 database is 300 MB and the transaction log size is 1000 MB, so it will fail when you try to perform the restore and throw the error mentioned earlier.

Now, if you had only set the primary data file (.mdf) to 500 and left the transaction log (.ldf) with a value under 1000 MB and tried restoring to a higher version such as SQL Server 2012, it will work because the newer versions have a higher base value.  This problem will also create itself naturally as your database grows and fills up with data, or if you issue too many SQL commands in an instance, causing the transaction log to fill up too quickly.

The Solution

The solution is fairly simple.  You can try recovering unused database space by shrinking it.  Right click on your local database instance and select Tasks -> Shrink -> Database.  You can also shrink your database by opening a New Query window in SQL Server Management Studio and executing this SQL Statement:

DBCC SHRINKDATABASE (N’DatabaseName’, TRUNCATEONLY)

For example:

DBCC SHRINKDATABASE (N’AdventureWorks’, TRUNCATEONLY)

You can check the new values in the Initial Size (MB) column by right clicking on the database, selecting Properties and then Files.  Make sure the Initial Size (MB) of the primary data file is less than the value found in the DiscountASP.NET Control Panel and that the Initial Size (MB) of the transaction log file is less than 1000 MB (1 GB).  If the Initial Size (MB) of the primary data file is greater after you shrink it, then that means you just need to order more SQL Server disk space.