@JerryACSA

pstewart → credited JerryACSA → .

Hi .Kris.,

The issue you describe was fixed a few versions ago, and the Schema.php file from 4.4.0-beta2 contains the fixed version. I would check the installed version again and try reinstalling 4.4.0-beta2 if needed. You can fix that specific issue by editing the file mentioned in your error message and removing the word "array" from line 1235, but I would be concerned you may be missing other fixes.

F:\WebSites\website\web\modules\composer\sqlsrv\src\Driver\Database\sqlsrv\Schema.php on line 1235

It's possible to drop and add a primary key on an existing table, but the IDENTITY status (automatic numbering) of a column cannot be changed and only one is allowed per table so switching columns is a problem (although there is a more complex way to change IDENTITY status using ALTER TABLE...SWITCH described here: https://stackoverflow.com/questions/1049210/adding-an-identity-to-an-exi... ). IDENTITY can be changed when copying to a new table, but in this case the existing logic that creates a new column, deletes the old one and renames, would be overkill if copying to a new table and and prevent it from working.

KenKods' solution (MR 79 mentioned above) should work for this issue too, which creates a new table using the new data type for the column (bigint in this case) and no temporary columns, turns on SET IDENTITY_INSERT, and converts from int to bigint while copying all the data from the old table to the new one. Then it adds indexes and renames the tables without making any further changes to the columns. For some reason I got the error in comment #2 when I tried to use it.

KenKods, does the error in #2 mean anything to you? I don't know whether self::COMPUTED_PK_COLUMN_NAME shouldn't be blank, or if it should but isn't handled properly. That code isn't part of this change but didn't like something when trying to run this update. I used Schema.php from MR 79 with a few changes to get it up-to-date with the sqlsrv driver since the MR was written, and attached it here. It should be current as of 4.4.0-beta2. I don't have tools to use or create patch files so I've patched files manually. Thanks for looking at this and for your MR!

Anyone, since the changeField function starts a transaction before it makes changes, does that address the concerns in #3 and #5 about data loss if other changes are being made during the update?

Yes, I used a workaround. During the update to 10.1 or higher and before running update.php, manually convert the field using the following SQL (in SQL Server Management Studio or another option):

ALTER TABLE watchdog ALTER COLUMN wid bigint NOT NULL

You can optionally add WITH(ONLINE=ON) to the end on SQL Server 2016 or newer if you want to use that option. I didn't use it.

Then, prevent the update function in core\modules\dblog\dblog.install from attempting the change, while allowing it to be marked as complete. Right after the following line (125 in my current copy),

function dblog_update_10101(&$sandbox = NULL) {

I added:

return;

Then run update.php and it should be successful. You have manually completed the changes just as if the driver could handle it. No future consideration needs to be given as a result of using the workaround other than the possibility that a change to an identity field in another table could cause the same type of issue if this hasn't been fixed yet.

I'm not familiar with 9.5 but unless it has the watchdog table upgraded to a bigint type wid column, the issue will appear on an upgrade to 10.1. It's not specifically related to 10.0. I don't see any mention of backporting the 3081144 issue to Drupal 9. If it was, this issue would probably occur during any update that included it on SQL Server. A clean install of 10.1 or higher should work fine since it doesn't need to change an existing table.

I did some research on the standards. As poker10 pointed out, XHTML requires the type attribute on script tags. HTML5 says type should be omitted for JavaScript, although it is still allowed. W3C indicates that the XHTML recommendation has been superseded and links to HTML5.

Our site uses XHTML so I held off on the advagg 7.x-2.36 update but since there haven’t been any comments, I eventually tried installing it. It did remove the type attributes yet the site continues to work just as before. Maybe the browsers are still lenient even though I read XML syntax was supposed to be strict. Technically it’s generating invalid XHTML. It seems that the pages work anyway.

Twelve lines above this change it’s adding almost twice as many characters as this saves to be compatible with XHTML and HTML4, so if compatibility is the intent it seems like this type should be put back. Maybe there could be a configuration option or automatic detection to only remove the type on HTML5 pages, although removing it is such a small savings it hardly seems worth it unless it’s causing HTML5 sites to fail some kind of validation.

Since updates are infrequent, I think I’ll just edit my copy of advagg.module for now to undo this patch after each update, unless this is changed. It doesn’t seem to be causing any harm but why not keep the XHTML valid when it’s that easy.

In these cases of running update scripts after an update, no one else should be accessing the database so any of these methods should be fine and I don't think we need to worry about concurrent access or data loss. However, it's a driver for generic database commands and I don't know if other functions or modules might change an identity field type while other users are actively using the table. It doesn't seem very safe to do that, so maybe it isn't done.

I'll see what you come up with regarding MR79.

(Corrected my upgrade/update terminology to be in line with documentation)

I tried the Schema.php file from MR 79 in issue 3263493 with the array keyword removed from createTableSql as has been done in a more recent update. The only other changes from 4.4.0-beta1 are related to that fix. I ran the database update again and got a different error. It looks like createPrimaryKey tries to insert self::COMPUTED_PK_COLUMN_NAME between the empty parentheses SQL Server complained about but for whatever reason that's empty. I'll have to look at it after the July 4 holiday.

dblog module
Update #10101
Failed: Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42000]: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Incorrect syntax near ')'.: ALTER TABLE [watchdog] ADD CONSTRAINT [watchdog_pkey] PRIMARY KEY CLUSTERED (); Array ( ) in dblog_update_10101() (line 135 of D:\inetpub\wwwroot\drupal\core\modules\dblog\dblog.install).

JerryACSA → created an issue.

I managed to set up a small Drupal 10 site on Windows using this sqlsrv driver 4.3.1 with a few changes. It's been running for the past month or two with no database issues I'm aware of since the initial troubleshooting/setup. I haven't reviewed the entire module for other changes that might be needed, run any testing tools or tried every possible Drupal function but the site works. Below is a log of what I did to fix each issue I encountered as a problem/solution list. I hope this helps with this effort, and I would be happy to help test any patches and the final version. It looks like the two patches I needed have since been committed to 4.3.2 or 4.4.x-dev, so that leaves my own changes below (or something similar) that is still needed.

PHP Fatal error: Declaration of Drupal\sqlsrv\Driver\Database\sqlsrv\Schema::createTableSql($name, array $table)
must be compatible with Drupal\Core\Database\Schema::createTableSql($name, $table)
in D:\inetpub\wwwroot\drupal\modules\sqlsrv\src\Driver\Database\sqlsrv\Schema.php on line 1235
fix: patch Schema.php to remove "array " from declaration:
old line 1235: protected function createTableSql($name, array $table) {
new line 1235: protected function createTableSql($name, $table) {

Error: Call to a member function fetchField() on null in D:\inetpub\wwwroot\drupal\modules\sqlsrv\src\Driver\Database\sqlsrv\Schema.php on line 765
fix: install patch from https://www.drupal.org/project/sqlsrv/issues/3291199 🐛 Call to a member function fetchField() on null Fixed "Call to a member function fetchField() on null"

PHP Warning: Undefined array key "default" in D:\inetpub\wwwroot\drupal\modules\sqlsrv\src\Driver\Database\sqlsrv\Connection.php on line 660
same warning on line 686
could occur on other nearby lines
see: https://www.drupal.org/node/3257198 →
fix: replace code in Connection.php in setPrefix($prefix) and tablePrefix($table = 'default')
new version of Connection.php attached as text file (includes next item too).

Message on Drupal installation page "Requirements problem" (step 3 Verify Requirements): Database connection does not support JSON.
fix: install patch #5 from https://www.drupal.org/project/sqlsrv/issues/3332118 📌 Database JSON support required Fixed "Database JSON support required"

Drupal\Core\Extension\MissingDependencyException: Unable to install modules: module 'sqlsrv' is incompatible with this version of Drupal core.
fix: patch modules\sqlsrv\sqlsrv.info.yml, change core_version_requirement: ^9.3 to ^10 (my changes are specific to Drupal 10, not for 9 anymore).

Thank you for the patch witwar! I reviewed the code changes and can confirm that it changes the PHP 7 "a ?? b" syntax to the PHP 5 compatible "isset(a) ? a : b" syntax correctly according to the documentation. The proper expressions were copied to the correct part of the syntax. There may be a duplicate semicolon at the end of the first changed line 91 though it works with or without it as expected for an empty statement. Nothing else was changed.

I applied the patch and confirmed that my site now works with the patched version of 7.x-1.14 on PHP 5.6.40. It fixed the blank page issue.

My site also stopped working when installing this update. Every page including the maintenance pages displayed an almost blank page with an error about an unexpected ? (question mark). I'm new to this but I think it could be the same issue if your site is not set to display errors in the browser. I investigated and it turns out Multiupload Filefield Widget 7.x-1.14 uses a new operator in PHP 7, ?? (double question mark). My site has PHP 5.6.40 is installed, which is supported for Drupal 7 but no longer recommended (see https://www.drupal.org/docs/7/system-requirements/php-requirements → ). Since the old syntax was replaced with the new ?? operator in six places, I'm guessing the code was intentionally updated to the newer PHP syntax. I restored the previous version of this module to get the site working again until I can update PHP.

Should there be a note or requirement somewhere saying this module requires PHP 7 or newer? The operator could also be changed back if that was not intentional since it's basically just a shorter way to accomplish the same thing.

If anyone else is having this issue and uses an older version of PHP, I would recommend upgrading PHP to version 7 or newer.