Ο Sql Server ΔΕΝ ΧΡΕΙΑΖΕΤΑΙ κόλπα για να υποστηρίξει τα ελληνικά!
Έχω προσέξει τελευταία ότι η ερώτηση που απαντάω πιο συχνά στο dotnetzone ή στη δουλειά είναι "Τί χρειάζεται για να περάσω ελληνική ηµεροµηνία/αριθµό στον Sql Server/στο .NET/στη VB6 ?" ή η παραλλαγή της "O Sql Server είναι στα αγγλικά και το PC στα ελληνικά. Τί να κάνω?". Και το επιστέγασµα όλων "Έγραψα ελληνικά στον Sql Server και τώρα µου γυρίζει ερωτηµατικά. Τί πρέπει να κάνω?".
Και η απάντηση σε όλα τα παραπάνω είναι ΤΙΠΟΤΑ! Σε όλες τις περιπτώσεις τα προβλήµατα εµφανίστηκαν επειδή κάποιος έκανε κάποιο λάθος προσπαθώντας να "διορθώσει" τη συµπεριφορά του Sql Server ή της VB6 ή του .NET.
Ας πάρουµε τα πράγµατα µε τη σειρά ξεκινώντας µε την ευκολότερη ερώτηση: Πως αποθηκεύουµε ελληνικά/ινδικά/φαρσί σε αγγλικό/νιγηριανό/ρωσικό Server? Απλά αποθηκεύοντας σε πεδία nchar/nvarchar/ntext. Τα πεδία αυτά είναι φτιαγµένα για να αποθηκεύουν strings σε Unicode. Εντωµεταξύ, η VB6 και φυσικά το .NET χρησιµοποιούν Unicode για όλα τα strings τους οπότε δεν υπάρχει κανένα πρόβληµα µετατροπής µεταξύ VB6 ή .NET και Sql Server. Αν κάνουµε σωστή δουλειά και χρησιµοποιούµε stored procedures ή έστω parameterized queries η ιστορία τελειώνει εδώ. Αν θέλουµε όµως να τεστάρουµε κώδικα στα γρήγορα και δηµιουργούµε το Sql statement µε string concατεnατionσ, πρέπει να θυµηθούµε να βάλουµε και ένα N µπροστά από κάθε string.
Τα προβλήµατα εµφανίζονται όταν αποθηκεύουµε σε πεδία varchar, ή αντιγράφουµε δεδοµένα varchar µεταξύ Server µε διαφορετικές γλώσσες ή µέσω εφαρµογής που τρέχει σε άλλη γλώσα. Αυτά τα πεδία είναι ASCII και χρησιµοποιούν συγκεκριµένα codepage . By default, ο Sql Server θα προσπαθήσει να µεταφράσει τα strings που του έρχονται στο κατάλληλο codepage αλλά τί µπορεί να κάνει αν δεν υπάρχει αντιστοιχία µεταξύ ελληνικών και ρουµανικών χαρακτήρων? Πέρα από το να βάλει ένα ? στη θέση του προβληµατικού χαρακτήρα, όχι πολλά.
Κι ερχόµαστε στο ελαφρώς πιο ενδιαφέρον θέµα των δεκαδικών και των ηµεροµηνιών. Εφόσον χρησιµοποιούµε stored procedures ή parameterized queries για να περάσουµε τιµές τύπου date, double, decimal κλπ. δεν θα εµφανιστεί κανένα πρόβληµα. Αν όµως τεµπελιάσουµε και "χτίσουµε" το Sql statement µε concατεnατionς είναι πολύ πιθανό να έχουµε πρόβληµα. Αυτό συµβαίνει επειδή η εφαρµογή µας θα µετατρέψει τους αριθµούς ή τις ηµεροµηνίες σε string χρησιµοποιώντας τις ρυθµίσεις του χρήστη που την εκτελεί. Αν αυτές διαφέρουν από τις ρυθµίσεις του Server, ο καηµένος ο Server δεν θα ξέρει τί να το κάνει το Sql statement ! Για φανταστείτε, στη µέση ενός where statement να βρεθεί ξαφινκά ένα κόµµα. Ή µία διεύθυνση 1/11/2005. Αυτό τώρα τί είναι, 1η Νοέµβρη ή 11η Gενάρη?
Αν βέβαια χρησιµοποιούµε παραµέτρους δεν έχουµε κανένα πρόβληµα. Αν όµως θέλουµε ντε και καλά να φτιάξουµε το Sql statement σαν string, πρέπει να ακολουθήσουµε κάποιους κανόνες.
Καταρχήν, περνάµε τα αριθµητικά δεδοµένα πάντα χρησιµοποιώντας την τελεία ως υποδιαστολή. Στην VB6 αυτό επιτυγχάνεται µε το function Str(). Αυτό είναι ίσως και το µόνο σηµείο όπου πρέπει να χρησιµοποιούµε την Str() αντί για την CStr(), η οποία λαµβάνει υπόψη της ρυθµίσεις του χρήστη.
Δεύτερον, δεν αφήνουµε ποτέ στην τύχη την µετατροπή των ηµεροµηνιών σε string. Φροντίζουµε πάντα να τις µετατρέπουµε στη µορφή 'yyyyMMdd' το οποίο είναι ένα από τα δύο τα οποία είναι εγγυηµένο ότι θα τα καταλάβει σωστά ο Sql Server. Το άλλο είναι η µορφή {d yyyy-MM-dd} (χωρίς εισαγωγικά) η οποία απλά απαιτεί µερικούς χαρακτήρες παραπάνω χωρίς να προσφέρει κάτι. Τις µετατροπές αυτές µπορούµε να τις πετύχουµε µε την Format στην VB6 ή την τostring("yyyyMMdd") στο .ΝΕΤ.
Ποιό είναι το συµπέρασµα? Ότι µπορούµε να περάσουµε νούµερα και ηµεροµηνίες εύκολα στον Sql Server χωρίς να κάνουµε τίποτα!