Closed (fixed)
Project:
Drupal driver for SQL Server and SQL Azure
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
26 Sep 2012 at 18:23 UTC
Updated:
25 Jun 2020 at 15:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
damien tournoud commentedYes we can add this check, but someone needs to come up with a patch! :)
Comment #2
rob_johnston commentedOK... since there may not be any obvious technical limitations, now let's get into the details.
The checkEncoding function for postgres calls "SHOW server_encoding" and expects "UTF8" in return. I believe that for sqlsrv this would be equivalent to "SELECT CONVERT (varchar, SERVERPROPERTY('collation'))" and the response expected is "SQL_Latin1_CP1_CI_AS".
However, I think it would be better to do this for the specific database used for Drupal:
"SELECT CONVERT (varchar, DATABASEPROPERTYEX('" . $database . "','collation'))"
Again, the same response of "SQL_Latin1_General_CP1_CI_AS" is expected.
Whether the database is case insensitive or not is determined by "_CI" or "_CS", but I don't think that there's a good test to determine if the database is unicode or not (isn't this done on the column level?). However, "EXECUTE sp_helpsort" and "SELECT * FROM fn_helpcollations() do give long strings which may or may not contain the work "unicode". So how would unicode support at the database level be determined?
Comment #3
damien tournoud commented@rob_johnston: all the types that we are using are Unicode (ie. they are the "n" variants:
nvarchar,ntext, etc.). The only thing that need to be checked is if the collation is correctly case insensitive.Comment #4
rob_johnston commentedI think that I originally though of this to avoid issues such as what occurred in #1144620: Fix character collation problems
Here's my untested suggestion:
Comment #5
Uncle_Code_Monkey commentedPatch created after some minor tweaks to the code.
I added the return FALSE statements to prevent any further processing since the message text seemed to imply it was essential and should stop if the collation was wrong. I also added a $_SESSION message because I couldn't see any text if I visited
install.phpon an existing database like I had to do. If this isn't proper, feel free to remove it. Anyway, I tested it with my existing database and it passed with a _CI collation and failed when it did not have such a collation.Comment #7
beakerboyThe 7.x branch is unsupported fixed in 8.x-1.x