Καλησπέρα σας, επειδή η ώρα ειναι 2 το πρωί, σας επισυνάπτω την απορία μου  που την εθεσα σε ενα ξενόγλωσσο φορουμ, και δεν ελαβα καποια πιστική απάντηση.... Την αντιγράφω εδώ, ίσως κάποιοι να την εχετε απαντήσει,αλλά δεν ξέρω δεν βρήκα τιποτα παρόμοιο με την απορία που έχω.
Σημείωση εχω εκτελέσει και το DTS για να δώ αν γίνεται και αν αλλάζει κάτι...

Perhaps you already have seen and have explained this.
I had a database in SQL Server 2000, as Latin_SQL collation and had problems with my native (greek).
What I did, is after googling around, to use this :

ALTER DATABASE myDB COLLATE Greek_CI_AS

Changed from varchar to nvarchar the field,
Restarted the server
and now I see the Greek.
What bugs me now, is that every field still reports, if I click the design table option, SQL_LATIN just like before!
To finish up, I altered the database, I changed the nvarchar, I see Greek, I didn;t do migration of data or rebuild of master or anything more bizarre, and it WORKS!

When this solution blows?
(The database is in cooperation with a .net application)
Thank you in advance...

Να σημειώσω επίσης οτι οταν κάναμε με δεξί κλίκ, στο manager τη βάση να εχει collation GREEK_CI_AS η λυση με το nvarchar δεν δουλεψε. Παρολαυτά το query δείχνει να παίζει.

Σας ευχαριστώ εκ των προτέρων

Αλλάζοντας το COLLATION (ALTER DATABASE mydb COLLATE Greek_CI_AS)  ή/και το Character Set (ALTER DATABASE mydb CHARACTER SET latin1 COLLATE Greek_CI_AS)  της Database δεν μπορείς δηστυχώς να αλλάξεις το COLLATION των υπάρχοντων πινάκων, αλλά μόνο αυτων που θα δημιουργηθούν από την εκτέλεση της εντολής και μετά.
Άλλοστε αυτό αναφέρετε καθαρά στο MSDN:
http://msdn2.microsoft.com/en-us/library/ms143726.aspx* Το άρθρο αυτό πιστεύω θα σου ξεκαθαρίσει αρκετά πράγματα, όπως τα: Server Collation, Database Collation, Table Collation κλπ.

*:Αντιγράφω το ΝΟΤΕ που έχει το παραπάνω άρθρο:
Note:
Altering the database-level collation does not affect user-, table-, or column-level collations.'

Ίσως αν δοκίμαζες το Column Level Location... 

---

Nothing to declare...

Σε ευχαριστώ για τη αναφορά που μου έδωσες, και είναι λογικό μπορεί να θες να αλλάξεις μια παράμετρο αλλά οχι και να επηρρεάσεις τα παλιά δεδομένα σου. Αλλά το θέμα, είναι εκτελώντας το ALTER DATABASE ερώτημα, ειναι απαραίτητο η μεταφορά των δεδομένων σε νέα βάση τελικά ; Γιατί στα διάφορα walkthrough, ή που έχω ακούσει για τέτοιες δουλειές πάντα καταλήγουν στο οτι πρέπει να κάνουν το DTS. Ομως βλέπω οτι η εφαρμογή δουλεύει, και η βάση έχει και τα παλιά δεδομένα και τα καινούρια. (Σημείωση ότι οταν ηταν γραφή τύπου Γραμμική Β: βλέπε : #???@2???? παρέμειναν στο ίδιο μοτίβο τα παλιά δεδομένα. Στην καινούρια και μετά απο την αλλαγή, δεν άλλαξαν αυτά τα ορνιθοσκαλίσματα.)

Οπότε βγάζω το συμπέρασμα οτι δεν χρειάζεται τελικά migration...σωστά ;

m6s:

Οπότε βγάζω το συμπέρασμα οτι δεν χρειάζεται τελικά migration...σωστά ;

Χμ... όσο αφορά στο Data Transformation Services και στο Data Migration,... εγώ στη θέση σου θα δοκίμαζα να μεταφέρω με DTS κάποιον πίνακα,... έτσι για δοκιμή, για να δω αν θα "παίξει" σωστά...
Π.χ.:
Θα έφτιαχνα έναν ΝΕΟ πίνακα με Greek collation όμοιο από κάποιον παλαιό (που παρουσιάζει το φαινόμενο της... "γραμμικής Β"!!)  και θα δοκίμαζα να μεταφέρω δεδομένα από τον παλαιό στον νέο.
Μετά θα δοκίμαζα σε υπάρχοντες "παλαιούς" πίνακες να αλλάξω το collation
κ.ο.κ.

Σημείωση: Το alter database θα αλλάξει το collation βάση ακόμα και αν, αργότερα, σε αυτήν κάνεις restore κάποια παλαιότερη βάση με άλλο Collation.

PS: Προσωπικά προτιμώ να πειραματίζομαι μόνος μου και να βλέπω με τα "δικά" μου μάτια την συμπεριφορά ενός Software / Hardware κλπ, παρά να βασίζομαι 100% σε κάτι που διάβασα ή που μου είπε κάποιος, που είτε μπορεί να είναι λάθος είτε να μην ισχύει στην δική μου περίπτωση...
Εξάλλου η διαδικασία αυτή σου προσφέρει και... γνώση.   

---

Nothing to declare...

Σύναδελφε στη θάλασσα της πληροφορικής(λογω avatar), ενοείται αυτό περί προσωπικής ερευνας και τελικά μάθησης, απλά ρωτάω γνώμη και γνώση αλλων και έχωντας κάνει και οσα πειράματα θα μπορούσα να σκεφτώ.

Σε ευχαριστώ πάντως.Για την αμεση αποκριση σου.

Δεν υπάρχει λόγος πανικού ούτε χρήσης κανονιών για να λυθεί το συγκεκριμμένο πρόβλημα, το οποίο είναι μεγέθους μάλλον ... μύγας.

Πρώτον, το collation δεν έχει να κάνει (και τόσο) με το αν θα φαίνονται ή όχι τα ελληνικά, αλλά με τον τρόπο που γίνεται το sorting. Από τη στιγμή που χρησιμοποιείς nvarchar (και κακώς δεν το χρησιμοποιούσες από την αρχή!), το collation σε επηρρεάζει κυρίως σε Inner joins και WHERE clauses. Αν προσπαθείς να κάνεις join μεταξύ στηλών με διαφορετικό collation ο SQL Server μπορεί να γκρινιάξει. Αν οι στήλες έχουν το ίδιο collation, δεν έχεις κανένα πρόβλημα

   Δεύτερον, το collation που ορίζεις σε ένα επίπεδο χρησιμοποιείται σαν default για την δημιουργία αντικειμένων του επόμενου επιπέδου. Έτσι, όταν ορίζεις το collation ενός πίνακα, ορίζεις το default για τις νέες στήλες, όταν ορίζεις βάσης, αντίστοιχα, ορίζεις το default για τους νέους πίνακες. Από τη στιγμή που δημιουργηθεί ένα αντικείμενο πρέπει να κάνεις ALTER το ίδιο για να αλλάξει το collation. 
   Για να αλλλάξεις το collation των columns αρκεί ένα ALTER COLUMN. Μπορείς να φτιάξεις μάλιστα ένα script το οποίο θα διαβάζει τα ονόματα των columns από το αντίστοιχο system table και θα εκτελεί το αντίστοιχο ALTER COLUMN. Η φασαρία και η μανούρα με DTS, rebuild της master και τα σχετικά είναι για όταν θέλεις να αλλάξεις το collation ολόκληρου του server. 
      Συνήθως όμως κάτι τέτοιο είναι περιττό! Ακόμα και αν αφήσεις το collation σε Latin, τα query σου θα παίξουν χωρίς πρόβλημα. Ακόμα και αν κάποια στιγμή χρειαστεί να χρησιμοποιήσεις ένα συγκεκριμμένο collation, μπορείς να το κάνεις προσθέτωντας το στο SELECT ή στο JOIN statement.

Θα σου συνιστούσα λοιπόν να μην πειράξεις παραπέρα τη βάση και να ασχοληθείς με το collation μόνο όταν διαπιστώσεις ότι υπάρχει πρόβλημα.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Παναγιώτης Καναβός:

Δεν υπάρχει λόγος πανικού ούτε χρήσης κανονιών για να λυθεί το συγκεκριμμένο πρόβλημα,...

Παναγιώτη συγγνώμη αλλα δεν έχω καταλάβει τι εννοείς?
Πέρα από το collation (alphbetization - ordering) πως θα λυθεί το πρόβλημα με τα "μη" Ελληνικά?
Εννοείς οτι με το Alter Column θα "διορθωθούν" και τα Ελληνικά ή όχι...?

---

Nothing to declare...

Εννοώ ότι δεν υπάρχει πρόβλημα, αλλά μάλλον δεν το εξήγησα αρκετά στο post μου. ΔΕΝ ΕΧΕΙΣ πρόβλημα αν χρησιμοποιείς nvarchar πεδία και το collation είναι Latin. Τα Ελληνικά θα εμφανιστούν κανονικότατα. Το collation δεν επηρεάζει το πως φαίνονται οι unicode χαρακτήρες. Αν δεν εμφανίζονται τα ελληνικά, κάποιο πρόβλημα υπάρχει στον client και όχι στο server.

Πρόβλημα μπορεί να έχεις αν πας να κάνεις join μεταξύ πεδίων με διαφορετικά collations, π.χ.  Latin Case Insensitive με Latin Case Sensitive. Το πρόβλημα θα εμφανιστεί λόγω του case, καθώς στο ένα πεδίο οι τιμές "Γάτος" και "γάτος" θα θεωρούνται οι ίδιες, ενώ στο δεύτερο όχι.

Όσο η βάση σου χρησιμοποιεί ένα και μοναδικό collation, δεν έχεις κανένα απολύτως πρόβλημα. Άν θέλεις να το σκαλίσεις παραπάνω πάντως, ρίξε στο "Mixed Collation Environments" του Books Online.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Ναι, είναι καθαρό.
Εγώ μάλλον νόμιζα οτι έλεγες οτι με την αλλαγή του collation διορθονώταν και το πρόβλημα με το character encoding. Πράγμα που συμβαίνει σε μη Unicode κωδικοποίηση*.
Thnx για την διευκρίνηση.

*Με το collation μπορείς να επηρεάσεις το Code Page αλλά μόνο σε non-unicode datatypes (char, varchar, text).
O λόγος είναι οτι το 2ο byte που χρησιμοποιεί η κωδικοποίηση UNICODE για τους χαρακτηρες (ένας χαρακτήρας = 2 bytes στην κωδικοποίηση UNICODE) ορίζεται από τα Unicode Standards και όχι από το CodePage (Πηγή).

 

---

Nothing to declare...

Γι αυτό και ΔΕΝ πρέπει να χρησιμοποιεί κανείς non-unicode πεδία, όπως varchar ή text. Μετά πρέπει να προσέχεις να βάζεις παντού το σωστό encoding, αλλιώς ... κλάφτα.

Είχε τύχει να δω κάποιον να προσπαθεί να περάσει ελληνικούς varchar χαρακτήρες από βάση με Latin collation σε βάση με ... Ρουμάνικο collation. Το αποτέλεσμα ήταν ένα μάτσο από ερωτηματικά στη θέση των ελληνικών δεδομένων. Κι όμως, ο τύπος επέμενε ότι δεν έπρεπε να αλλάξει το πεδίο σε nvarchar ...

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Σας ευχαριστώ για την ανάλυση, καταλαβαίνω καλύτερα τώρα τι γίνεται, σίγουρα.
Αυτό που σίγουρα παραμένει κιόλας ειναι οτι οταν εχω αλαμπουρνέζικα αλλαζωντας το Collation δεν τα διορθώνεις.
Τα χάνεις, ας είχες βάλει nvarchar....σωστά;

Και λυπάμαι δεν ειχα παρει πρέφα οτι η συζήτηση συνεχιζόταν!!

Ευχαριστώ αλλη μια φορά.

Υπάρχουν αλαμπουρνέζικα και αλαμπουρνέζικα. Αν βλέπεις "κινέζικα", μπορείς να το σώσεις το πράγμα. Αν βλέπεις ερωτηματικά, τα έχασες. Αυτό που συνέβει, είναι ότι ακριβώς συμβαίνει και με τις ελληνικές σελίδες που εμφανίζονται "κινέζικα". Έχουν αποθηκευτεί με λάθος codepage οπότε όταν εσύ προσπαθείς να τις δεις, το αποτέλεσμα είναι αλαμπουρνέζικο. Τα ερωτηματικά είναι χειρότερα. Αυτό σημαίνει ότι κατά την αποθήκευση των varchar ο SQL Server δεν βρήκε αντιστοίχιση μεταξύ των χαρακτήρων των codepage του client και του πίνακα, με αποτέλεσμα κάποιοι χαρακτήρες να μην μπορούν να αποθηκευτούν και να αντικατασταθούν με ερωτηματικά. Το ίδιο μπορεί να συμβει και αν προσπαθήσεις να αντιγράψεις varchar δεδομένα από ένα πίνακα με π.χ. ελληνικό collation σε π.χ. ρουμάνικο. Με το Unicode δεν έχεις κανένα πρόβλημα.

Ο SQL Server προσπαθεί αυτόματα να μετατρέψει τους χαρακτήρες από το codepage του collation στη γλώσσα του client. Αν έχεις σώσει ελληνικά σε ελληνικό collation και προσπαθείς να τα διαβάσεις από αγγλικό client, η μετατροπή θα πετύχει (εφόσον ο client χρησιμοποιεί Unicode, π.χ. κάθε εφαρμογή .NET). Αν όμως αποθηκεύσεις ελληνικά σε αγγλικό collation και πας να τα διαβάσεις σε αγγλικό μηχάνημα, η μετατροπή δεν θα γίνει και θα δεις κινέζικα. Αν πας να διαβάσεις σε π.χ. ρουμάνικο μηχάνημα, η μετατροπή μπορεί να αποτύχει εντελώς και να δεις ερωτηματικά.

Αν βλέπεις κινέζικα, μπορείς να σώσεις την κατάσταση ορίζοντας το collation που θέλεις στα select σου, κάτι αντίστοιχο με το να ορίσεις το σωστό codepage σε ένα web page. Μην δοκιμάσεις όμως να αλλάξεις απλά σε nvarchar τη στήλη αν έχει λάθος codepage. Αν έχεις αποθηκεύσει ελληνικά σε Latin collation και αλλάξεις τον τύπο, o SQL θα προσπαθήσει να αντιστοιχίσει τα ελληνικά γράμματα σε λατινικούς χαρακτήρες και θα πάρεις πάλι κινέζικα, ενώ μπορεί και να μην πιάνει πλέον η χρήση του collation στα select. Πρώτα διόρθωσε το collation και μετά άλλαξε τον τύπο.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Το collation που ειχα ήταν SQL_Latin1_GENERAL_850_CI_AI στο οποίο γύρισα σε nvarchar αλλα πρίν ειχα κανει ενα ALTER COLLATION dbname GREEK_CI_AS. Σωστός ; ναι νομίζω.
Αν ειμαι οκ, σε αυτό τότε ακομα μια απορία :

Οταν αλλαξα το collation με ερώτημα η παραπάνω διαδικασία εκανε τα ελληνικά απο εδώ και πέρα να δουλεύουν.
Σε μια αλλη δοκιμή αντι για SQL ερώτημα ALTER.... πηγα και αλλαξα στον manager το collation με πολύ ...παραθυρική νοοτροπία, κλικ, επιλογή, κλίκ το collation ΟΚ. Μετα αλλαξα παλι το varchar σε nvarchar...Αλλα η συνταγή..."έκοψε". Επρεπε να κανω κατι παραπάνω που δεν κάνει ο manager οταν αλλάζω το collation μεσα απο αυτόν ;

Εν'τέλει για μια σωστή βάση που να έχει αγγλικα, ελληνικά αν ειναι δυνατόν και κινέζικα, ( για unicode δεν μιλάμε; ) πώς στήνεται;
Διότι στα ξένα site εχει πέσει μεγάλη παίδευση ρε παιδιά με τα κινέζικα και τα αγγλικά, αλλά αυτό το greek μόνο εμείς το θυμόμαστε τελικά...
Και πάντα...αργά. ;-) Τουλάχιστον για εμένα!!

Ευχαριστώ πολύ ξανά

Απλά βάζεις nvarchar και τελείωσες. Τόσο απλό είναι να στήσεις μία βάση για ελληνικά και αγγλικά και ρώσικα και κινέζικα και όλα μαζί.

 Από εκεί και πέρα, φροντίζεις να χρησιμοποιείς παντού unicode strings, ακόμα και στις εντολές. Αν δεν βάλεις μπροστά από ένα string το γράμμα N, π.χ. N'Ονοματεπώνυμο' o SQL Server θα θεωρήσει ότι του δίνεις τιμή varchar. Αυτό θα πρέπει να το προσέξεις ειδικά αν χρησιμοποιείς χύμα SQL για να περάσεις παραμέτρους. Αν βέβαια χρησιμοποιείς πάντα stored procedures ή parameterized queries δεν θα έχεις πρόβλημα. Ακόμα και στα stored procedures όμως θα πρέπει να προσέχεις όταν χρησιμοποιείς strings μέσα στα queries.

Το τελευταίο σημείο στο οποίο μπορεί να την πατήσεις μετά είναι η εφαρμογή. Αν η εφαρμογή δεν χειρίζεται τα strings ως Unicode μπορείς να έχεις πάλι πρόβλημα. Τέτοιες περιπτώσεις μπορεί να είναι εφαρμογές σε C++ ή Delphi που χρησιμοποιούν ANSI strings αντί για double-byte strings.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Παναγιώτης Καναβός:

...

Το τελευταίο σημείο στο οποίο μπορεί να την πατήσεις μετά είναι η εφαρμογή. Αν η εφαρμογή δεν χειρίζεται τα strings ως Unicode μπορείς να έχεις πάλι πρόβλημα. Τέτοιες περιπτώσεις μπορεί να είναι εφαρμογές σε C++ ή Delphi που χρησιμοποιούν ANSI strings αντί για double-byte strings.

Για να μην γίνει καμιά παρεξήγηση και νομίσει κάποιος οτι π.χ. το Delphi δεν υποστηρίζει Unicode Characters να πούμε οτι, αν θες να τους χρησιμοποιήσεις, μπορείς να τους δηλώσεις ως εξής:

var s : WideString;
    c : WideChar;

---

Nothing to declare...