Question

Ben K on Tue, 11 Sep 2012 12:43:48


Hello,

I'm having problems migrating Drupal 7 from our current server (Windows 2008, IIS7, PHP 5.2, SQL Server 2005) to a new one (Windows 2008R2, IIS7.5, PHP 5.4 NTS with FastCGI 32bit, SQL Server 2008).

I installed the SQL Native Client 2012 as well as SQL/PHP Driver 3.0. The website itself runs fine and delivers content. But when I try to clear the cache Drupal tells me that "an error occured on the server". I've set pdo_sqlsrv.log_severity = 1 in php.ini.

These are errors I get in the PHP error log:

[11-Sep-2012 10:51:01 UTC] pdo_sqlsrv_dbh_set_attr: SQLSTATE = IMSSP
[11-Sep-2012 10:51:01 UTC] pdo_sqlsrv_dbh_set_attr: error code = -39
[11-Sep-2012 10:51:01 UTC] pdo_sqlsrv_dbh_set_attr: message = The given attribute is only supported on the PDOStatement object.
[11-Sep-2012 10:51:01 UTC] pdo_sqlsrv_stmt_fetch: SQLSTATE = IMSSP
[11-Sep-2012 10:51:01 UTC] pdo_sqlsrv_stmt_fetch: error code = -15
[11-Sep-2012 10:51:01 UTC] pdo_sqlsrv_stmt_fetch: message = The active result for the query contains no fields.
[11-Sep-2012 10:51:05 UTC] pdo_sqlsrv_stmt_execute: SQLSTATE = 42S02
[11-Sep-2012 10:51:05 UTC] pdo_sqlsrv_stmt_execute: error code = 208
[11-Sep-2012 10:51:05 UTC] pdo_sqlsrv_stmt_execute: message = [Microsoft][SQL Server Native Client 11.0][SQL Server]Ungültiger Objektname 'profile_field'.
[11-Sep-2012 10:51:06 UTC] pdo_sqlsrv_stmt_fetch: SQLSTATE = IMSSP
[11-Sep-2012 10:51:06 UTC] pdo_sqlsrv_stmt_fetch: error code = -15
[11-Sep-2012 10:51:06 UTC] pdo_sqlsrv_stmt_fetch: message = The active result for the query contains no fields.
[11-Sep-2012 10:51:06 UTC] pdo_sqlsrv_stmt_fetch: SQLSTATE = IMSSP
[11-Sep-2012 10:51:06 UTC] pdo_sqlsrv_stmt_fetch: error code = -15
[11-Sep-2012 10:51:06 UTC] pdo_sqlsrv_stmt_fetch: message = The active result for the query contains no fields.
[11-Sep-2012 10:51:06 UTC] pdo_sqlsrv_dbh_last_id: SQLSTATE = IMSSP
[11-Sep-2012 10:51:06 UTC] pdo_sqlsrv_dbh_last_id: error code = -46
[11-Sep-2012 10:51:06 UTC] pdo_sqlsrv_dbh_last_id: message = An error occurred retrieving the last insert id.

The thing is, when I began to set up this server I didn't install SQL Server 2008 first, instead I pointed the installation to the old web server running SQL Server 2005. So only the Native Client 2012 was installed. From what I remember I had no issues clearing the cache. Only since the install of SQL Server 2008 on the webserver this error occurs (I don't know about the errors in the error log above since I didn't have set pdo_sqlsrv.log_severity enabled).

Does anyone know what could be the reason for this problem?

Best Regards,

Ben


Sponsored



Replies

Robert Johnson on Wed, 12 Sep 2012 09:07:11


I'd like to help but can't.  On this forum we need to see the code that calls the sqlsrv driver, and the sql statement.  The errors don't reveal what the problem is.

Drupal is the client of the driver, so you will have to ask a Drupal forum.

You have made quite a few upgrades at the same time... SQL Server, IIS, PHP, and the SQLSRV driver. 

I recommend upgrading to the very latest version of Drupal, following the instructions on their site, then asking a Drupal forum if the problem persists.

  • SQL Server + sqlsrv PHP driver upgrade: the driver handles DateTime differently in server 2008 - I do not know how this affects Drupal or whether it makes any difference.
  • IIS upgrade - should not make a difference.
  • PHP upgrade - a lot changed from 5.2 to 5.4, might be worth investigating if Drupal requires some changes to its settings, or you need to change your php.ini settings.

Ben K on Fri, 14 Sep 2012 16:14:12


Thanks for your answer.

I was able to solve the Cache-Clearing-issue. The reason was that the database user only had the db_datareader and db_datawriter roles and was not allowed to execute TRUNCATE since it's an DDL operation (see http://msdn.microsoft.com/en-us/library/ms177570.aspx). I added the db_owner role and now it's working. So the main issue I was having had nothing to do with the errors I posted above.

However while the site seems to be fine those errors still do occur. I also enabled error tracing on the old (current) server and now I have the very same errors all over the php error log! I just never noticed because logging is disabled by default, and they don't show up in Drupal.

I guess that these errors may be expected and catched in the Drupal layer. Nevertheless I've posted the problem in the Drupal forum as you recommended (http://drupal.org/node/1784744), just to verify.

BR,
Ben

pincushionman on Wed, 10 Oct 2012 14:51:58


I had a problem with the PDO_SQLSRV driver myself.  This parameter

PDO:ATTR_PERSISTENT => true 

(set when you create your PDO object) appears to work.  However, it caused my PHP-CGI and PHP-CLI processes to crash each time.  Removing this parameter - well specifically all parameters - from the new PDO statement causes PDO to work great.

This has been tested on PHP v5.3 and v5.4 setups.

I found this bug when I tried to recycle the $dbh variable (with the same server and such), and the PDO_SQLSRV driver told me, "You can't do that, it's unsupported."

Robert Johnson on Wed, 10 Oct 2012 15:32:50


Agreed - I can reproduce that.

First connection works with PDO::ATTR_PERSISTENT, but subsequent connections cause the crash.