-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Expanded definitions and updated for SQL Server 2017 #161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Expanded definitions of "CodePage", "LCID", and "ComparisonStyle" properties so that they aren't a mystery to most people who don't know where to get those definitions. I copied the 4 bitmask values for "ComparisonStyle" from [DATABASEPROPERTYEX]( https://docs.microsoft.com/en-us/sql/t-sql/functions/databasepropertyex-transact-sql) but did not copy the "for example" portion as that seemed extraneous. But, if it is best that it be here for consistency then I can add it in. Regarding the link used for "LCID": the page has the value in hex which requires the extra step of converting the INT value returned here, but that list is by far the most complete that I could find. In fact, I couldn't find any other list that included entries for values 0x00010407 through 0x00040411. Regarding the addition to the "Version" info: I confirmed that info on SQL Server 2017 as **3** is returned for the new Japanese collations (i.e. the `Japanese_Bushu_Kakusu_140_` series and the `Japanese_XJIS_140_` series).
|
Thank you @srutzky for the edits. @edmacauley please review. |
|
Thanks @srutzky for expanding these definitions. Looks great to me. #sign-off |
|
@edmacauley and @craigg-msft I have a question about links to other documentation. Is there a rule about external references? Such as to Wikipedia or blog posts? (And while not a concern for the moment, if blog posts are ok, is it acceptable to reference my own blog, assuming it is the best reference for the info, or is that considered poor form due to it being self-serving / conflict of interest type of stuff?). But back to the issue at hand: the update I made here linked to MS documentation for Code Page mappings. I just found out while doing some research and trying to use those mappings as a resource, that at least one of them, Code Page 1257 Windows Baltic Rim is wrong in a few places. That documentation is not editable so I cannot fix it. Can I reference Windows-1257 on Wikipedia? In which case maybe it is best to be consistent and use Wikipedia for all of those mappings? On the plus side, there are two Code Pages missing from the MSDN documentation (1258 and one other) and at least 1258 is on Wikipedia, hence it is more complete. Thoughts? Also, on a somewhat related note, I did notice that while I was doing my best to conform to the existing style convention, I had used the "code" formatting and upper-case for the word |
|
@srutzky Thank you for the question and interest in helping with content. Linking to other relevant sources is ok as long as there a clear note about the purpose of the link, such as "For a current list of code pages, see xyx". With that said the links should be for occasional references and support of the core article. It would not be a good user experience if an article how a lot of external references and the "reading flow" essentially has some clicking back and forth. As a general rule, blogs are ok if they are current, relevant, and the URL appears like it will be consistent. The problem with some blogs is the link is to the current topic of the blog and next month of next post will make the same URL reference different content. It also depends on who much relevant information is in the blog vs summarizing directly into the topic. A lot of it comes down to making the users learning experience and flow as smooth and click free as possible. Referencing other sources can enhance the overall learning experience but we also want to keep a reasonable balance between that and our topics just being used as a launching point to send users all over the place. yes, if you have the time to make that style change to varbinary, It would be great. I hope this helps and thanks again for your time. |
|
@craigg-msft Thanks for that info and I understand those concerns and goals. When the time comes, I will ask about specific blog posts. I found something else to update on that page, so I made the varbinary and even _BIN / _BIN2 styles more consistent while I was in there. I submitted it via #175 |
Even if the particular changes for this file in this PR aren't "significant", the date still should have been changed when I did make significant updates via MicrosoftDocs#161 on Oct 15th. At least this way there is consistency across the 3 files given that the changes all revolve around the new Japanese / _VSS collations.
Expanded definitions of "CodePage", "LCID", and "ComparisonStyle" properties so that they aren't a mystery to most people who don't know where to get those definitions. I copied the 4 bitmask values for "ComparisonStyle" from DATABASEPROPERTYEX but did not copy the "for example" portion as that seemed extraneous. But, if it is best that it be here for consistency then I can add it in.
Regarding the link used for "LCID": the page has the value in hex which requires the extra step of converting the INT value returned here, but that list is by far the most complete that I could find. In fact, I couldn't find any other list that included entries for values 0x00010407 through 0x00040411.
Regarding the addition to the "Version" info: I confirmed that info on SQL Server 2017 as 3 is returned for the new Japanese collations (i.e. the
Japanese_Bushu_Kakusu_140_series and theJapanese_XJIS_140_series).