I am running drupal 7.12 on Windows and Sql Server. I ran update.php for 7.14 and have hit a problem. The Node module update 7013 and the system module update 7073 both are trying to modify a field. In both cases the update fails because the field is involved in a dependency:
node module
Update #7013
Failed: PDOException: SQLSTATE[42000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Object 'node.vid' cannot be renamed because the object participates in enforced dependencies.: EXEC sp_rename :old, :new, :type; Array ( [:old] => node.vid [:new] => vid_old [:type] => COLUMN ) in db_change_field() (line 2985 of C:\_code\PAi\Source\DEV\Websites\Corporate\Web\includes\database\database.inc).
system module
Update #7073
Failed: PDOException: SQLSTATE[42000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Object 'file_managed.uri' cannot be renamed because the object participates in enforced dependencies.: EXEC sp_rename :old, :new, :type; Array ( [:old] => file_managed.uri [:new] => uri_old [:type] => COLUMN ) in db_change_field() (line 2985 of C:\_code\PAi\Source\DEV\Websites\Corporate\Web\includes\database\database.inc).
The module is just calling the drupal db_change_field function, so it must be the sql server driver that is choosing to do a rename. at any rate, the dependency I can find is a unique index on both of these fields which really would fail if a rename is done.
We have been running this configuration since 7.08 and this is the first time we have encountered this.
Any suggestions?
Comments
Did a little more digging and
Did a little more digging and found the problem, though I am not sure what the fix is.
the problem is the function in the driver that goes out an looks for unique indexes. I'll use the node table as an example, but the file_managed has the same issue. For reasons I don't quite understand, there is a computed column, __unique_vid based on the vid column that is getting updated. This __unique_vid column is what is actually used in the unique index, not the vid column.
Here is the code with the problem, it is passing the actual field name, but does not know that the field is actually in a computed column:
protected function dropFieldRelatedObjects($table, $field) {
// Fetch the list of indexes referencing this column.
$indexes = $this->connection->query('SELECT DISTINCT i.name FROM sys.columns c INNER JOIN sys.index_columns ic ON ic.object_id = c.object_id AND ic.column_id = c.column_id INNER JOIN sys.indexes i ON i.object_id = ic.object_id AND i.index_id = ic.index_id WHERE i.is_primary_key = 0 AND i.is_unique_constraint = 0 AND c.object_id = OBJECT_ID(:table) AND c.name = :name', array(
':table' => $this->connection->prefixTables('{' . $table . '}'),
':name' => $field,
));
As a result the unique index is not dropped, and the rename fails because the column is used in the computed column.
Ideas of who can help with this?
The same to you... The
The same to you...
The following updates returned messages
node module
Update #7013
Failed: PDOException: 在 db_change_field() (行 2985 在 C:\Users\Fertony\Documents\My Web Sites\Acquia Drupal 7\includes\database\database.inc).
system module
Update #7073
Failed: PDOException: 在 db_change_field() (行 2985 在 C:\Users\Fertony\Documents\My Web Sites\Acquia Drupal 7\includes\database\database.inc).
in WebMatrix and SQL server 2008R2, who can help me?
Also with Views update
views module
Update #7301
Failed: PDOException: SQLSTATE[42000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Object 'views_view.name' cannot be renamed because the object participates in enforced dependencies.: EXEC sp_rename :old, :new, :type; Array ( [:old] => views_view.name [:new] => name_old [:type] => COLUMN ) in db_change_field() (line 2985 of C:\OtherWebSites\Hs3\includes\database\database.inc).
This is becoming a real issue for those of us running IIS and MSSQL.
Having same issue
We are having the same issue as well, running IIS and MSSQL Server 2008. Is there a work around for this in the meantime? Any help would be appreciated, stuck in a bind now trying to update.
FYI: There's a issue report
FYI: There's a issue report about it here: http://drupal.org/node/1561396
So far it's unfortunately not been resolved, and I'm not seeing much action on the maintainers part to get it fixed as of yet.
Katherine Shaw, Front-end Developer, Lullabot
I have posted a patch here,
I have posted a patch here, http://drupal.org/node/1526404. Any of you following this issue, could you try to apply it and see if it works for you?