In system.module the date_format_locale table is defined as (case insensitive) (see update system_update_7078) :
'description' => 'The date format string.',
'type' => 'varchar',
'length' => 100,
'not null' => TRUE,
But the date_formats has the format field case sensitive:
'description' => 'The date format string.',
'type' => 'varchar',
'length' => 100,
'not null' => TRUE,
'binary' => TRUE,
Both fields should be 100% compatible as they represent the same thing.
When trying to compare both fields on SQL Server, you get a PDO Exception because, commonsense, you cannot compare a case sensitive and case insensitive field (unless you specifically cast to case sensitive or insensitive on the fly):
PDOException: SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot resolve the collation conflict between "Latin1_General_CS_AI" and "Modern_Spanish_CI_AS" in the equal to operation.: SELECT df.dfid, df.format, df.type, df.locked, dfl.language FROM {date_formats} df LEFT JOIN {date_format_locale} dfl ON df.format = dfl.format AND df.type = dfl.type ORDER BY df.type, df.format; Array ( ) en _system_date_formats_build() (línea 3791 de modules\system\system.module).
I have looked to Drupal 8 code and these tables are all gone.
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | fix_collation.zip | 611 bytes | david_garcia |
| #1 | 2376239-format-case-sensitive.patch | 970 bytes | david_garcia |
Comments
Comment #1
david_garcia commentedComment #2
dean.p commentedHi, thanks for your continued work on this, however, I tried this patch and Drupal still fails on install with WSOD. The reason I was going fort this option was to try and solve a SQL error with views archive... that's how I found my way to this post.
Comment #3
david_garcia commented@dean.p Please follow this issue reporting tips.
I haven't run a D7 clean install from the repo for a long time because we a running on a forked core, I'll give it a shot with latest official version of everything.
WSOD is helpful, please review you logs and post the exact error message. Unless this is a PHP process crash (wich I doubt) you should be able to get a description of the error, probably in the PHP log.
Comment #4
david_garcia commentedI can confirm D7 latest official release is perfectly passing install on MSSQL after applying this patch.
Comment #5
dobe commentedI ran the update for this and received this error:
PDOException: SQLSTATE[42000]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Cannot resolve the collation conflict between "Latin1_General_CS_AI" and "SQL_Latin1_General_CP1_CI_AS" in the equal to operation.: SELECT df.dfid, df.format, df.type, df.locked, dfl.[language] FROM date_formats df LEFT JOIN date_format_locale dfl ON df.format = dfl.format AND df.type = dfl.type ORDER BY df.type, df.format; Array ( ) in _system_date_formats_build() (line 3798 of C:\inetpub\wwwroot\intranet.drupal\modules\system\system.module).Comment #6
dobe commentedI take my last statement back. You need to run the update with SQLSRV version 1, then you can use SQLSRV version 2. I got ahead of myself :D
Comment #7
dobe commentedI can confirm this patch solved my issues. It seems like a harmless straight forward approach as well.
Comment #8
orangesi commentedI'm getting the following error after after going through the Drupal setup:
"SQLSTATE[42000]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Cannot resolve the collation conflict between "Latin1_General_CS_AI" and "SQL_Latin1_General_CP1_CI_AS" in the equal to operation."
OS: Windows Server 2008 R2
DB server: SQL Server 2014
PHP version: 5.4.12
Drupal version: 7.38
Drupal 7 driver for SQL Server and SQL Azure version: 7.x-2.0-beta5
I ran across this site because before setting up Drupal via SQL Server, it says:
"To install this version of the MS SQL Server driver make sure you have this patch in core: https://www.drupal.org/node/2376239"
The problem is that I don't know how to apply the fix to the file:
\modules\system\system.install
Using Notepad++ to edit the system.install file... Can someone explain how to edit on the file?
original system.install file: https://www.dropbox.com/s/i7ksolt4jooce7u/system%20-%20original.install?...
modified system.install file: https://www.dropbox.com/s/eam563904su1w47/system.install?dl=0
Is the modified system.install file correct? All I added was the following to the end of the file:
+ * Convert the 'format' column in {date_format_locale} to case sensitive varchar.
+ */
+function system_update_7080() {
+ $spec = array(
+ 'description' => 'The date format string.',
+ 'type' => 'varchar',
+ 'length' => 100,
+ 'not null' => TRUE,
+ 'binary' => TRUE,
+ );
+ db_change_field('date_format_locale', 'format', 'format', $spec);
+}
+
+/**
Comment #9
dobe commentedWell the best way to apply a patch is using git with documentation found here: https://www.drupal.org/patch/apply
But if you want to just past it in. Make sure to remove the + signs at the beginning of each line. Those are additions by the patch saying they are new lines.
Based on your modified install you did it correctly. Just make sure to run the install after you are using the patched file.
Comment #10
orangesi commentedThanks dobe!
Unfortunately I'm not familiar with git to apply patches :(
I've removed the + signs (forgot to mention that they were removed)
The only thing left is based on the patch:
https://www.drupal.org/files/issues/2376239-format-case-sensitive.patch
It shows another + which I haven't included:
+ 'binary' => TRUE,
I'm not sure where to add this to the system.install file. Would you know where I need to add it to?
Comment #11
dobe commentedBased on your modified version on dropbox. Your almost there! Two things that will cause this to freak out. That is your $spec variable. needs to be a variable. Right now you have it as just spec. The array variable is $spec. Which is getting passed to the db_change_field function.
Also when looking at the "patch" file you can see right where you need to put that other 'binary' => TRUE,
Look at where it says: @@ -800,6 +800,7 @@ function system_schema() { look at the surrounding text around the added line as well. That should give you a pretty good hint of where to put it.
That means at around line 800 in your file or within the "system_schema() function is where you will find the array to add it.
function system_update_7080() {
$spec = array(
'description' => 'The date format string.',
'type' => 'varchar',
'length' => 100,
'not null' => TRUE,
'binary' => TRUE,
);
db_change_field('date_format_locale', 'format', 'format', spec); <----- spec should be $spec
}
I have added the file so you can just download it. But feel like I should let you know some tricks.
Comment #12
orangesi commentedThanks dobe! It's now working :)
For those that don't use or don't know how to use git for patching and using Drupal 7.38..
Edit system.install file from root drupal folder /modules/system
1. Insert an empty line after 802 and paste:
2. Insert an empty line after 3161 and paste:
Comment #13
David_Rothstein commentedCommitted to 7.x - thanks!
Comment #16
Anonymous (not verified) commentedI am getting the "Cannot resolve the collation conflict" error on my update.php run AFTER updating to 7.41. I even went and checked the system.install file that was patched here and the updated corrections are in place.
My site seems to work otherwise, I just cant successfully run update.php due to the error:
PDOException: SQLSTATE[42000]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Cannot resolve the collation conflict between "Latin1_General_CS_AI" and "SQL_Latin1_General_CP1_CI_AS" in the equal to operation.: SELECT df.dfid, df.format, df.type, df.locked, dfl.[language] FROM date_formats df LEFT JOIN date_format_locale dfl ON df.format = dfl.format AND df.type = dfl.type ORDER BY df.type, df.format; Array ( ) in _system_date_formats_build() (line 3811 of system.module).
Any idea what could cause this issue?
Comment #17
dobe commentedLikely caused because your using 7.x-2.x of sqlsrv before updating? Could be wrong but I remember having similar issues in #5.
Comment #18
Anonymous (not verified) commentedYeah I updated to 7.x-2.x a couple weeks ago. I will revert back and then re-update to see if that works..
Comment #19
david_garcia commented@drclayt0n Sorry no automated upgrade path. You can contribute one if you want.
If 7.x worked for you, you are better off sticking with the previous versions even if unsupported. There are structural changes between 7.1.x and 7.2.x I can't even imagine how you guys are moving from one to another without the whole thing bursting into flames.
Comment #20
Anonymous (not verified) commented@david_garcia hopefully nothing is on fire - i gave it a shot with 7.1 and unfortunately i could not run update.php without the error. However, when I run update.php the error is show along with "no pending updates". So perhaps its nothing huge to worry about at the moment. Like I said, the site still seems to function normally, its just update.php where I get that error.
I am thinking of possibly trying to fix my issue by reverting your updated files to what they were in core version 7.39. If I reverted back only the files you submitted (system.install, system.module), would that damage anything else updated to 7.41 on my site?
Comment #21
Anonymous (not verified) commentedSomeone suggested changing the format coalition directly in sql server on the format column. It seemed to work and get rid of the error. https://www.drupal.org/node/2608386#comment-10533224
Comment #22
david_garcia commentedSee attached ZIP with sql statement needed to fix the collation issue on systems that where installed before this was commited into core and did not manually apply the patch.
Comment #23
WolfPlayer commentedThanks David. I tested your script and it works great. The order shouldn't matter but I ran your script against my instance, did the latest update to 7.41 (from 7.39), updated the sqlsrv module manually, and then updated my modules. Everything running smoothly.
Comment #24
ricky93 commentedI patched the file, but then where will I place the paid php mssql? Since there is no driver folder? (Does it just go in the inlcudes/database/sqlsrv?) Or do I link the file with the patch?