SQL Server database collation

ความแตกต่างของ Database Collation
Thai_CI_AI คือ Language ภาษาไทย
   CI = Case Insensitive 
   AI = Accent Insensitive

ต่างกับ Thai_CI_AS คือ
AS = Accent Sensitive

แนะนำใช้ Thai_CI_AI  เพราะ Thai_CI_AS จะมีปัญหาเกี่ยวกับภาษาไทยเรื่องของตัวการันต์
เช่นหากเราเขียน QUERY

SELECT * FROM customer WHERE Name LIKE 'พิมพ%'

หาก Collation เป็น Thai_CI_AS   คนที่ชื่อ พิมพ์ใจ จะไม่ออกมาตามที่ควรจะเป็นครับ
นอกจากนั้นแล้ว Column ใน Table ก็มี Collation ของตัวเองอีกด้วย
ดังนั้นตอน Install Server หรือ Create Database ควรต้องระวังเรื่องนี้ด้วยครับ

Reporting Service (SSRS) , Subscription Locale

เรื่อง ภาษาของเครื่อง ณ เวลาที่ทำ Reports Subscription
มีความรู้เล็ก ๆ น้อย ๆ มาฝากเกี่ยวกับภาษาของเครื่อง ในตอนที่เราทำ Subscription ครับ
หากรายงานของเรามี parameter ที่เป็นวันที่แล้วต้องการให้มี default เป็นช่วงเวลาที่กำหนด
อย่างของผม กำหนดให้เป็นวันที่ 1 - สิ้นเดือนของเดือนที่ผ่านมา  สามารถทำได้ครับ
โดยการเขียน Script ในตัว parameter ของรายงาน  แต่เมื่อทำ Subscription โดยให้ User สามารถ
ทำเองได้ ปรากฏว่าเจอปัญหาที่ทำเอางงไปครึ่งวันกว่าจะหาเจอว่าเป็นเพราะอะไร
ปัญหาคือ วันที่ที่ได้เขียน Script  ไว้เกิดเพี้ยน  ไม่เป็นไปตามรูปแบบที่ต้องการ ทำให้รายงานรันผิด
ได้พยายามหาสาเหตุอยู่นาน แล้วก็ได้เจอครับ โดยเปิด Database ของ Reporting ขึ้นมาแล้ว
Select ดูจาก table subscriptions ทำให้เห็นความแตกต่างของฟิลด์ ๆ นึงคือ Field "Locale" ครับ
ซึ่งตัวนี้เองเป็นตัวที่กำหนดรูปแบบของวันที่ในรายงานที่ทำ Subscription ผมจึงจัดการ update
โดยใช้ SQL ธรรมดากันเลยครับ  ไม่งั้นต้องมานั่งทำใหม่ใช้เวลานานมาก

SQL script for update locale

UPDATE Subscriptions
set locale ='en-US'
WHERE  locale = 'th-TH'

เท่านี้เป็นอันเรียบร้อยสบายตัวไป ^ ^

Reporting Service (SSRS) , Date format problem in parameter

ปัญหาเรื่องรูปแบบวันที่ใน Parameter ของ Reporting service
จากปัญหาที่พบในเครื่องของ User คือ รูปแบบของวันที่แตกต่างจากที่กำหนดไว้ใน Report
เช่นใน Report กำหนดเป็น mm/dd/yyyy แต่เครื่อง User เป็นแบบ dd/mm/yyyy ทำให้รายงานเกิด Error
ปัญหานี้เกิดขึ้นเนื่องมาจากการ Setting ค่าใน Internet Options ครับให้ดูตามรูปตัวอย่าง

เลือก วันที่จาก Calendar

ค่าที่ได้จากการเลือกวันที่

หากมีการจัดลำดับให้ ภาษาไทยอยู่ก่อน English

จะได้รูปแบบวันที่ที่เปลี่ยนไปตามนี้ จะเห็นว่าจาก 4/28/2010 จะกลายเป็น 28/4/2010

MDX Query : Getdate()

บทความนี้จะอธิบายถึงวิธีการใช้งาน Function Getdate() ใน MDX Query
ปกติหากจะหาวันที่ปัจจุบันใน SQL Server จะใช้ Function Getdate() และจัด Format ตามต้องการ
เช่น  SELECT Convert(char(8),Getdate(),112)
แต่หากเป็นใน MDX Quey แล้ว จะแตกต่างกันไปนิดหน่อยโดยใช้ Function NOW() แทนครับ
ดูตามตัวอย่าง และนำไปประยุกต์ใช้เอาตามชอบใจ


WITH
MEMBER [Measures].[CurYear] as -- Current Year (Full)
Format(NOW(), "yyyy" )
MEMBER [Measures].[CurYearShot] as -- Current Year (With 2 digits)
Format(NOW(), "yy" )
MEMBER [Measures].[CurMonthFull] as -- Current Month (Full)
Format(NOW(),"MMMM")
MEMBER [Measures].[CurMonthNum] as -- Current Month (With 2 digits)
Format(NOW(),"MM")
MEMBER [Measures].[CurDateNum] as -- Current Date (With 2 digits)
Format(NOW(),"dd")
MEMBER [Measures].[CurDateFull] as -- Current Date
Format(NOW(),"d")
MEMBER [Measures].[CurDateFullFormat] as -- Current Date (With custom format)
Format(NOW(),"dd/MM/yyyy")
MEMBER [Measures].[PrvYear] as -- Previous Year
Format(DATEADD("yyyy",-1,NOW()),"yyyy")
MEMBER [Measures].[NxtYear] as -- Next Year
Format(DATEADD("yyyy",1,NOW()),"yyyy")
MEMBER [Measures].[PrvMonth] as -- Previous Month
Format(DATEADD("m",-1,NOW()),"MMMM")
MEMBER [Measures].[NxtMonth] as -- Next Month
Format(DATEADD("m",1,NOW()),"MMMM")
MEMBER [Measures].[PrvDate] as -- Previous Day
Format(DATEADD("d",-1,NOW()),"dd")
MEMBER [Measures].[NxtDate] as -- Next Day
Format(DATEADD("d",1,NOW()),"dd")
MEMBER [Measures].[YearDiff] as -- Difference between 2 years
DATEDIFF("yyyy",DATEADD("yyyy",-1,NOW()),DATEADD("yyyy",3,NOW()))
MEMBER [Measures].[ConvertStrToDate] as -- Convert String to Date
Cdate("1/28/2010")
select {[Measures].[CurYear],[Measures].[CurYearShot],[Measures].[CurMonthFull],[Measures].[CurMonthNum],
[Measures].[CurDateNum],[Measures].[CurDateFull],[Measures].[CurDateFullFormat],
[Measures].[PrvYear],[Measures].[NxtYear],[Measures].[PrvMonth],[Measures].[NxtMonth],
[Measures].[PrvDate],[Measures].[NxtDate], [Measures].[YearDiff],
[Measures].[ConvertStrToDate]} ON 0
FROM [Adventure Works]

Process OLAP dimensions error , "File system error: A FileStore error from WriteFile occurred. Physical file"

Error issued because "PROCESS UPDATE" large dimensions.
-------------------------------------------------------------
Event Type: Error
Event Source: SQLISPackage
Event Category: None
Event ID: 12550
Date: 4/18/2010
Time: 10:06:35 PM
User: OLAP-SERVER\SQLService
Computer: OLAP-SERVER
Description:
Event Name: OnError
Message: File system error: A FileStore error from WriteFile occurred. Physical file: \\?\E:\ Projects\OLAP\Data\olap_tsc301.0.db\Dim Card.14.dim\77.Dim Card.bsstore. Logical file: . .

Operator: MyServer\SQLService
Source Name: Process OLAP_TSC301 DIM
Source ID: {2cf2f9b3-07fb-490a-abca-eb7cf83c1c2b}
Execution ID: {D0810E33-4776-4B32-A15E-107267F343C4}
Start Time: 4/18/2010 10:06:35 PM
End Time: 4/18/2010 10:06:35 PM
Data Code: -1056833471
--------------------------------------------------------------------------
It happen when your dimension file is growth over 4GB.
And you choose PROCESS UPDATE method to process dimensions.
I have errors issued  and found on google search ,
to solve problem is FULL Process Cube for a moment. And I don't have a permanent solution to fix this problem.

I had this problem many times, until I found a totally unrelated article pertaining to a 4 GB limitation for the .asstore file in MOLAP dimensions. I talked to Microsoft, and they investigated and found that the limitation does exist. If it happens again, I would suggest browsing the data folder where the database exists and opening the failing dimension folder. If you see that the dimension file with a .asstore extension, or any other one that is over 4 GB, you have found your problem. There is nothing short of doing a full process on the dimension (which the Microsoft guy suggested, and I had to yell at him (in a nice way)) when it hits the limit. If you MUST Process Update and you cannot use ProcessAdd on your dimension, I would suggest breaking the dimension in a linear fashion into several dimensions (column by column), or finding a new way to build the dimension where it will not grow exponentially. A Process Update appends string data to the file, and that is why it gets so large. I would also suggest taking a look at the AS dimension and see if there are any character columns you can cut down in size.

Ref site. http://geekswithblogs.net/darrengosbell/archive/2007/04/29/SSAS-ProcessUpdate---Too-much-of-a-good-thing.aspx