Jump to content

Server collation sql 2008


Billytsik
 Share

Recommended Posts

Καλησπέρα.

Έχουμε στήσει πρόσφατα έναν sql 2008 r2 standard edition και αφήσαμε το server collation κατά το installation στο SQL_Latin1_General_CP1_CI_AS.

Όλες μας οι εφαρμογές δούλεψαν άψογα.

Tο data base collation που έχουν οι βάσεις μας είναι το Greek_CI_AS.

Σήμερα έκανα και την μεταφορά της βάσης του προγράμματος της μισθοδοσίας.

Παρατηρήσαμε ότι είχαμε πρόβλημα στην εμφάνιση ελληνικών στις έγραφες της εφαρμογής. (το περιβάλλον της εφαρμογής εμφανίζει κανονικά ελληνικά ΔΕΝ είναι πρόβλημα regional settings)

Μετά από πολλά τηλεφωνήματα με την Έψιλον και κόπο καταλήξαμε στο ότι φταίει το ότι έχουμε server collation SQL_Latin1_General_CP1_CI_AS παρόλο που η βάση έχει Greek_CI_AS.

 

Έψαξα λοιπόν να βρω το εάν αλλάζει το server collation χορισ να γίνει επανεγκατάσταση ολόκληρου του server.

Βρήκα αυτό: http://www.esds.co.in/forum/f4/change-sql-server-collation-2751/

 

setup.exe /q /ACTION=RebuildDatabase /INSTANCENAME=MSSQLSERVER

/SAPWD="password" /SQLSYSADMINACCOUNTS="BUILTIN\ADMINISTRATORS"

/SqlCollation=CollationName

 

 

 

Από ότι καταλαβαίνω κάνει rebuild την master DB ?

Η ερώτηση μου είναι τι ακριβώς θα προκαλέσει αυτή η αλλαγή.

Είναι production server και δουλεύουν επάνω του χρήστες και υποκαταστήματα που συνδέονται σε άλλες βάσεις.

Ποιο πολύ με ενδιαφέρει να καταλάβω τι αντίκτυπο θα έχει αυτή η αλλαγή στις υπόλοιπες βάσεις και γενικότερα στον sql server.

 

Ευχαριστώ πολύ.

 

 

Link to comment
Share on other sites

1ον. Κάνοντας rebuid την master αποκτάς μια νέα master που δεν ξέρει τίποτα από οτι μέχρι τώρα είχες, ούτε ρυθμίσεις, ούτε χρήστες, ούτε databases...., Άρα σκεψου καλά πριν κάνει αυτό σε production server.

Αυτό για να σε προλάβαω και σου απαντώ αργότερα για τα αλλά

Link to comment
Share on other sites

Οποτε το rebuild το ξεχνάμε δεν έχει νόημα στην περίπτωση μας.

Η άλλη λύση είναι να εγκαταστήσουμε ακόμα ένα instance και να παίξει εκεί.

Για αυτήν την περίπτωση έχω ακούσει ότι καλό είναι να αποφεύγεται για λόγους performance.

 

 

Link to comment
Share on other sites

Πριν κάνεις οτιδήποτε θα ήθελα να μου περιγράψεις με όσο το δυνατόν περισσότερες λεπτομέριες το story. Θα ήθελα να ξέρω πχ σε ποιά έκδοση ήταν η βάση πριν την πας σε R2, τι server collation είχε ο server που ήταν ποιο ήταν το database collation, με ποιό τρόπο έγινε η μεταφορά στο νέο server, γράψε μου σε παρακαλώ όσο το δυνατό περισσότερα για να αποκτήσω μια όσο το δυνατό ολοκληρωμένη εικόνα

Link to comment
Share on other sites

Ο παλιός είναι ένα μηχάνημα Win 2003 sbs

H sql είναι αυτή που συνόδευε τον sbs. 2005 workgroup edition 32bit με sp3.

Το Server Collation είναι Greek_CI_AS.

To Data Base Collation είναι Greek_CI_AS

 

Ο νέος είναι ένα Virtual μηχάνημα με Win Server 2008 r2 ent.

H sql είναι 2008 R2 Standard edition 64bit.

Το Server Collation είναι SQL_Latin1_General_CP1_CI_AS

To Data Base Collation είναι Greek_CI_AS

 

H βάση δημιουργήθηκε ως εξής.

-Εγκατάσταση από το το Epsilon_SetupDB.exe με επιλογή ενεργοποίησης χωρίς Epsilon instance.

Αυτό δημιούργησε μια κενή DB στον server Χωρίς να φτιάξει ξεχωριστό instance.

 

Πηγα στον παλιό πήρα την βάση backup και την έκανα restore στον καινούργιο.

 

 

Link to comment
Share on other sites

Το πρόβλημα οφείλεται στο ότι η εφαρμογή αποθηκεύει δεδομένα σε μορφή ASCII αντί για unicode στη βάση με αποτέλεσμα να εξαρτάσαι από το collation, τα regional settings και τον τρόπο που γίνεται η σύνδεση για το αν θα φανούν σωστά τα ελληνικά.

Το πρόβλημα εμφανίζεται όταν προσπαθείς να γράψεις στη βάση με ένα codepage ενώ αυτή περιμένει κάποιο άλλο. Το τί περιμένει η βάση εξαρτάται από το collation της βάσης ή του πίνακα. Οι περισσότερες βιβλιοθήκες (OLEDB, ODBC) όταν δουν ότι χρησιμοποιούνται διαφορετικά codepages μεταξύ βάσης και εφαρμογής θα προσπαθήσουν να μετατρέψουν τα strings από το ένα codepage σε Unicode για να τα στείλουν στο server και εκεί θα μετατρέψουν το Unicode στο δεύτερο codepage για να μην καταλήξουν "κινέζικοι" χαρακτήρες στη  βάση. Όσοι χαρακτήρες δεν αντικαθίστανται μετατρέπονται σε ? ή κουτάκια. Η αυτόματη μετατροπή ελέγχεται από την παράμετρο AutoTranslate στο connection string. Στο ADO.NET δεν υπάρχει αυτό απλά γιατί τα πάντα στο ADO.NET είναι Unicode.

Αν τώρα άλλο είναι το codepage της εφαρμογής (ορίζεται από τα regional settings), άλλο της βάσης (ορίζεται από collation) και άλλα του γράφεις εσύ, θα έχεις πρόβλημα. Για παράδειγμα, αν πας να γράψεις ελληνικούς ASCII χαρακτήρες από αγγλικό locale σε βάση με ελληνικό collation, θα γίνει μπέρδεμα. Σε αυτό οφείλονται και οι "κινέζικοι" χαρακτήρες, είναι ASCII τα οποία "περάσανε" από λάθος μετατροπή.

Αυτό που με παραξενεύει είναι ότι λες ότι η βάση είναι σε Greek locale και στο νέο server αλλά το πρόβλημα παραμένει. Αυτό σημαίνει ότι η ίδια η εφαρμογή δεν υποστηρίζει Unicode και δουλεύει με ASCII codepages. Μήπως είναι Delphi? Γιατί ακόμα και η VB6 με Unicode δούλευε. Υποψιάζομαι ότι αυτό που "χαλάει" την εφαρμογή είναι το AutoTranslate, οπότε δοκίμασε να προσθέσεις το AutoTranslate=no ή AutoTranslate=false (OLEDB ή ODBC αντίστοιχα) μήπως διορθωθεί το πρόβλημα.

Η όλη ανακατωσούρα περιγράφεται και στο KB904803, όπου αναφέρει επίσης ότι "ΔΕΝ υποστηρίζεται η αποθήκευση non-Unicode δεδομένων από codepage X σε στήλη με διαφορετικό codepage". Αυτό είναι η άλλη μεγάλη (και πολύ συχνότερη_ πηγή προβλημάτων, όταν η εφαρμογή σώζει ελληνικά σε Latin στήλες.

Η πραγματική λύση φυσικά είναι η εφαρμογή να αρχίσει να χρησιμοποιεί Unicode αντί για ASCII. Όλα τα άλλα είναι "χανζαπλάστ" και μπορεί να σου λύσουν προσωρινά το πρόβλημα, δεν εξασφαλίζουν όμως ότι δεν θα εμφανιστεί ξανά στο μέλλον.

Αν έχεις όρεξη, ρίξε και μία ματιά στο "Ο Sql Server ΔΕΝ ΧΡΕΙΑΖΕΤΑΙ ΚΟΛΠΑ για να υποστηρίξει ελληνικά". Περιέχει τα παραπάνω λίγο πιο αναλυτικά, χωρίς το κομμάτι για το πως ακριβώς δουλεύει το AutoTranslate.

Link to comment
Share on other sites

Τα regional settings ειναι ιδια μεταξύ του 2003 και του 2008. για τα client ούτε λόγος αφού εάν συνδεθούν στο παλιό όλα δουλεύουν κανονικά.

Η εφαρμογή είναι η Μισθοδοσία extra Εpsilon Net.

Δεν ξέρω να σου πω σε τι είναι φτιαγμένη και με ποιον τρόπο σώζει στην βάση. (νομίζω είναι σε dot net 1.1)

Το πρόβλημα παντός δεν εμφανίζεται μόνο όταν γράφει αλλά και όταν διαβάζει από την βάση.

 

Όταν μίλησα το πρωί μετά παιδιά στην υποστήριξη μου είπαν οτι φταίει η το οτι το server collation SQL_Latin1_General_CP1_CI_AS δεν είναι ίδιο με

το data base collation Greek_CI_AS Και ότι η λύση είναι ή να ξανά περαστεί ο sql ή νέο instance. !!!

 

 

Link to comment
Share on other sites

Για κάνε έναν έλεγχο, οι πίνακες της βάσης του Epsilon Net έχουν πεδία με Greek_CI_AS collation? Το collation προχωράει μέχρι column level οπότε είναι πιθανό να είναι μεν ο πίνακας Greek_CI_AS αλλά τα πεδία SQL_Latin1_General_CP1_CI_AS. Μπορεί να φταίει ο τρόπος που η εφαρμογή δημιουργεί τη βάση...

 

Link to comment
Share on other sites

Θα έλεγα να κάνεις το εξής αν μπορείς εαν ακόμα έχεις τον αρχικό server. Μην δημιουργήσεις τη βάση μέσα από το setup του προγραμματος αλλά να την κάνεις restore από το backup που έχεις και μετά να πεις στο προγραμμα να την δει...

Link to comment
Share on other sites



Όταν μίλησα το πρωί μετά παιδιά στην υποστήριξη μου είπαν οτι φταίει η το οτι το server collation SQL_Latin1_General_CP1_CI_AS δεν είναι ίδιο με
το data base collation Greek_CI_AS Και ότι η λύση είναι ή να ξανά περαστεί ο sql ή νέο instance. !!!

.....

Αν είχα 1€ για κάθε φορά .... [:S]

Ο λόγος που ΔΕΝ ΠΡΕΠΕΙ ΝΑ ΧΡΗΣΙΜΟΠΟΙΕΙΣ ASCII είναι ακριβώς για να μην χρειάζεται να "καρφώνεις" τα settings για να παίξει η εφαρμογή. Και καλά αν έχεις μόνο ελληνικά δεδομένα. Αν όμως έχεις και κανένα πελάτη σε άλλη χώρα? Κανα ρουμάνικο collation ?

Αν χρησιμοποιείς ένα γερό SQL Server cluster για διάφορες εφαρμογές?

Άσε που αν θέλουν οπωσδήποτε να "καρφώσουν" το codepage, ας το κάνουν μέσα στην εφαρμογή, μετατρέποντας τα strings στο codepage που θέλουν με κώδικα πριν τα στείλουν στη βάση.

Πραγματικά, είναι ευκολότερο (effort = 0) να κάνεις τη δουλειά σωστά και να ορίσεις όλες τις στήλες nvarchar αντί varchar από την αρχή, παρά να προσπαθείς μετά να διορθώσεις τα προβλήματα έστω και ενός πελάτη.

 

Link to comment
Share on other sites

"Θα έλεγα να κάνεις το εξής αν μπορείς εαν ακόμα έχεις τον αρχικό server.

Μην δημιουργήσεις τη βάση μέσα από το setup του προγραμματος αλλά να

την κάνεις restore από το backup που έχεις και μετά να πεις στο

προγραμμα να την δει..."

 

Το έκανα αυτό που λες αλλά δεν βοήθησε.

Να προσθέσω ακόμα μερικές παρατηρήσεις που έκανα.

 Μέσα στους πινάκες της βάσης τα ελληνικά εμφανίζονται κανονικά.

Μπήκα στην εφαρμογή και παρόλο που δεν δούλευε σωστά δοκίμασα να κάνω μια εγγραφή για δω πως θα την σώσει.

Στην οθόνη όσο έγραφα στα πεδία έβλεπα ελληνικά.

Με το που πάτησα ενημέρωση τα ελληνικά έγιναν ASCII.

Κάνω select στον πίνακα που έκανα την εγγραφή και βλέπω ότι την πίρε κανονικά ελληνικά !!!!

Η βάση μιλάει και γράφει ελληνικά μια χαρά .

Το θέμα είναι η εμφάνιση τον ελληνικών στην εφαρμογή.

Η ερώτηση είναι: Είναι δυνατών μια εφαρμογή να κοιτάει το server collation αντί του db collation ?

και όταν κάνω εγγραφές γιατί δεν μου γράφει ASCII στους πίνακες? 

 

Link to comment
Share on other sites

Από όλα αυτά που λες καταλαβαίνεις ότι το θέμα δεν είναι o SQL Server... Το πως και τι κάνει η εφαρμογή δεν μπορώ να σου απαντήσω, αλλά σίγουρο είναι ότι ο κώδικας κάνει ότι του έχεις πει να κάνει...

Link to comment
Share on other sites

Μου φαίνεται τελικά ότι θα φτιάξω ένα hyper μηχάνημα με XP και express 2005  και θα το βάλω να τρέχει εκεί.

Αυτό του αξίζει να έχει και αυτό θα πάρει.

sqlcmd script για backup στον windows scheduler και τέλος.

 

Σασ ευχαριστω πολυ για τισ απαντισειες και τον χρόνο σας.

Να είστε καλά.

 

Link to comment
Share on other sites

ASCII γράφεται σε ένα πεδίο αν αυτό είναι τύπου varchar. Αν είναι τύπου nvarchar αυτό που γράφεται είναι unicode. Θα πρέπει να μας γράψεις το script του πίνακα για να καταλάβουμε τί γίνεται (δεξί κλικ στον πίνακα, Script Table As, Create) αλλά πάω στοίχημα ότι τα πεδία είναι varchar.

Το ότι κάνεις query και βλέπεις σωστά τα ελληνικά δεν είναι περίεργο. Και το Management Studio client είναι και υπόκειται στους ίδιους κανόνες με τις άλλες εφαρμογές. Το font που χρησιμοποιεί είναι Unicode συνεπώς πρέπει να μετατρέψει ότι διαβάζει σε unicode για να το δεις. Αν τα δεδομένα είναι unicode θα τα δεις κανονικά. Αν είναι ascii θα τα δεις σωστά μόνο αν τα collations είναι σωστά, αλλιώς και ο SSMS θα τα χάσει στα conversions. Αν η εφαρμογή σώσει το 0xΑ2 byte (Ά στο Windows Greek) σε πεδίο με λατινικό collation, τί θα πρέπει να σου δείξει το SSMS όταν πάει να διαβάσει αυτό το 0xA2 ? ¢

Ίσως να μπορέσεις να διορθώσεις την κατάσταση προσωρινά αλλάζοντας το system locale του server. Το λέω αυτό επειδή στο documentation του AutoTranslate λέει ότι το translaction γίνεται χρησιμοποιώντας τα ACPs του server και του client. ACP σημαίνει ANSI Code Page, με άλλα λόγια το System Locale.  Ίσως να διορθωθεί το πρόβλημα σου αλλάζοντας το System locale σε ελληνικό, ίσως όχι. 

Link to comment
Share on other sites


Όταν μίλησα το πρωί μετά παιδιά στην υποστήριξη μου είπαν οτι φταίει η το οτι το server collation SQL_Latin1_General_CP1_CI_AS δεν είναι ίδιο με
το data base collation Greek_CI_AS Και ότι η λύση είναι ή να ξανά περαστεί ο sql ή νέο instance. !!!

Πάντως πες στα παιδιά, αν θέλουν, να μπουν εδώ να μας εξηγήσουν πως τα κατάφεραν να υλοποιήσουν μια τέτοια εφαρμογή :))))

Link to comment
Share on other sites

Όταν μίλησα το πρωί μετά παιδιά στην υποστήριξη μου είπαν οτι φταίει η το οτι το server collation SQL_Latin1_General_CP1_CI_AS δεν είναι ίδιο με
το data base collation Greek_CI_AS Και ότι η λύση είναι ή να ξανά περαστεί ο sql ή νέο instance. !!!

Αν τώρα άλλο είναι το codepage της εφαρμογής (ορίζεται από τα regional settings), άλλο της βάσης (ορίζεται από collation) και άλλα του γράφεις εσύ, θα έχεις πρόβλημα. Για παράδειγμα, αν πας να γράψεις ελληνικούς ASCII χαρακτήρες από αγγλικό locale σε βάση με ελληνικό collation, θα γίνει μπέρδεμα. Σε αυτό οφείλονται και οι "κινέζικοι" χαρακτήρες, είναι ASCII τα οποία "περάσανε" από λάθος μετατροπή.

Αυτό που με παραξενεύει είναι ότι λες ότι η βάση είναι σε Greek locale και στο νέο server αλλά το πρόβλημα παραμένει. Αυτό σημαίνει ότι η ίδια η εφαρμογή δεν υποστηρίζει Unicode και δουλεύει με ASCII codepages. Μήπως είναι Delphi? Γιατί ακόμα και η VB6 με Unicode δούλευε. Υποψιάζομαι ότι αυτό που "χαλάει" την εφαρμογή είναι το AutoTranslate, οπότε δοκίμασε να προσθέσεις το AutoTranslate=no ή AutoTranslate=false (OLEDB ή ODBC αντίστοιχα) μήπως διορθωθεί το πρόβλημα.

Η όλη ανακατωσούρα περιγράφεται και στο KB904803, όπου αναφέρει επίσης ότι "ΔΕΝ υποστηρίζεται η αποθήκευση non-Unicode δεδομένων από codepage X σε στήλη με διαφορετικό codepage". Αυτό είναι η άλλη μεγάλη (και πολύ συχνότερη_ πηγή προβλημάτων, όταν η εφαρμογή σώζει ελληνικά σε Latin στήλες.

Welcome to the club. Μέσα απο το browser του SQL πάντα θα βλέπεις Ελληνικά. Το θέμα είναι ότι η Latin1 ναι μεν δείχνει Eλληνικά όπως και άλλες γλώσσες αλλά δεν υποστηρίζει encoding για μετατροπή χαρακτήρων πέρα των αγγλικών. Εαν η εφαρμογή σου διάβαζε Latin1 θα σου έδειχνε και Ελληνικά κανονικά. Τo Ελληνικό collation μπορεί να μετατραπεί σε Latin1 και σε UTF-8 και να δείχνουν Ελληνικά αλλά δεν παίζει το αντίθετο.

Το πρόβλημα με το Latin1 είναι universal και το αντιμετωπίζουν πολλοί ειδικά όσοι ασχολούνται με PHP. Εκεί προσπαθούν με μεταφράσουν δεδομένα σε Χ γλώσσα (Ελληνικά,Πολωνικά,Τσέχικα....) σε UTF-8. Δεδομένου ότι όλοι σχεδόν οι web hosters έχουν by default server collation Latin1 στη Mysql αν δεν είσαι Άγγλος καταλαβαίνεις το μέγεθος του προβλήματος. Βέβαια εκεί έχεις λύση με το SET_NAMES ( http://www.oreillynet.com/onlamp/blog/2006/01/turning_mysql_data_in_latin1_t.html ) μπορείς να δεις τι πατέντα χριεάζεται για να γίνει αυτό, το οποίο σε επίπεδο εφαρμογής δεν παίζει. H singularlogic έχει φτιάξει ειδικό εργαλείο για την μεταφορά δεδομένων απο βάσεις με διαφορετικό collation για αυτό το λόγο. Η epsilon που πήρες τηλέφωνο αφού δεν σου είπαν ότι έχουν κάποιο τέτοιο εργαλείο μη παιδεύεσαι άδικα. Ακόμα και σε .Net εφαρμογές το collation το παίρνει αυτόματα απο το Server. Οπότε....

Link to comment
Share on other sites

Απόστολε αυτά που λες δεν ισχύουν. Καταρχήν το Latin1 είναι απλά άλλο ένα collation, από την άλλη το UTF8 δεν υπάρχει στον SQL Server ούτε καν σαν έννοια. Πρόβλημα υπάρχει φυσικά στην MySQL που δεν ξεχωρίζει ANSI από Unicode και προσπαθεί όλα να τα χειριστεί ως ANSI με encodings. Είπαμε, ο SQL Server υποστηρίζει unicode εξαπανέκαθεν στα πεδία nvarchar, nchar, ntext και ΔΕΝ χρειάζεται κόλπα για να παίξει με οποιαδήποτε γλώσσα, ούτε ελληνικά. Εξάλλου το τί ισχύει για MySQL δεν έχει καμμία εφαρμογή για SQL Server.

Το μπέρδεμα που περιγράφεις είναι και η αιτία που διάφορες εφαρμογές δεν δουλεύουν σωστά με ελληνικά. Αν παίζεις μόνο με ANSI (varchar, char, text πεδία) θα σε κάψει το codepage. Αν βάλεις unicode δεν πρόκειται να χρειαστείς ποτέ εργαλείο για μετατροπή collation, όχι γι αυτό το λόγο τουλάχιστον.

Αν τώρα κάποιοι είχαν μαζέψει τόσα δεδομένα σε ASCII πεδία, λογικό να χρειάστηκαν εργαλεία. Αλλά όπως είπα και νωρίτερα, αυτό το ρημάδι το n στους τύπους δεν κοστίζει τίποτε, ούτε χρειάζεται εργαλεία.

 

Link to comment
Share on other sites

Συγγνωμη που παρεμβαινω ,εχω χασει επαφη με εφαρμογες της Εψιλον προ διετιας και δεν γνωριζω την τρεχουσα κατασταση.

Θυμαμαι ομως πως η Εψιλον όντας microsoft partner εβαζε τον sql2005 μαζι με την εφαρμογη της και ειδικα στην business ερχόταν και στηνόταν χωρις  παραμετροποιηση η SQL2005 std edition και μετα τα business ERPs. Γιατι δεν ρωτας τους ανθρωπους της Εψιλον να  σου απαντησουν στο θεμα σου? Προ διετιας ηταν αρκετα συνεργασιμοι και εδιναν συμβουλες καλες για τα προγραμματα τους.

Εκτος κι αν αλλαξε κατι απο τοτε?

 

 

Link to comment
Share on other sites

"Θα πρέπει να μας γράψεις το script του πίνακα για να καταλάβουμε τί

γίνεται (δεξί κλικ στον πίνακα, Script Table As, Create) αλλά πάω

στοίχημα ότι τα πεδία είναι varchar."

 

Το κερδίζεις το στοίχημα εύκολα.

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[EMPLOYEE](

    [iD_EMP] [int] NOT NULL,

    

 [varchar](50) NULL,

    [sURNAME] [varchar](50) NOT NULL,

    [NAME] [varchar](50) NULL,

    [FTHRNAME] [varchar](50) NULL,

    [MTHRNAME] [varchar](50) NULL,

    [VAT] [int] NULL,

    [bRTHDATE] [smalldatetime] NULL,

    [iDNUMB] [varchar](10) NULL,

    [iDDATE] [smalldatetime] NULL,

    [iDTMHMA] [varchar](50) NULL,

    [PHOTO] [image] NULL,

    [hrDATE] [smalldatetime] NULL,

    [FRDATE] [smalldatetime] NULL,

    [YEXP] [tinyint] NULL,

    [MEXP] [smallint] NULL,

    [DEXP] [int] NULL,

 

"Ίσως να διορθωθεί το πρόβλημα σου αλλάζοντας το System locale σε ελληνικό, ίσως όχι.  "

Είναι Ελληνικά παντού και στα non Unicode programs .

 

 

" Γιατι δεν ρωτας τους ανθρωπους της Εψιλον να  σου απαντησουν στο θεμα

σου? Προ διετιας ηταν αρκετα συνεργασιμοι και εδιναν συμβουλες καλες για

τα προγραμματα τους.

Εκτος κι αν αλλαξε κατι απο τοτε?"

Μια χαρά συνεργάσιμοι είναι και τώρα. Μονο που η σχέση έχουμε δεν είναι αμφίδρομη αλλά μονόδρομη. Απλοσ μου λενε τι πρεπι να κάνω. ή να ξανά περαστεί ο sql ή νέο instance. !!!

 

 

 

Link to comment
Share on other sites

Για να ενεργοποιηθούν Collation στον SQL Latin πρέπει να έχεις εγκαταστήσει των SQL σε Windows το οποίο εξαρχης δεν είχς σωστά Regional Setings για Locale και Language for non - Unicode Programs se GREECE

Αρα εγκατέστησες   English Language Locale  Windows Server αρχικά

- και μετά SQL 2008 με Latin Collation και 

- αλλαξες τα Regional Settings του Operating System σε Greece / Greek  μετά

Σε αυτήν την περίπτωση αν δηάδή η default εγκατάσταση OS Windows ήταν English Locale στα Regional Settings - μετά SQL - και μετά αλλαγή σε GREEK υπάρχει η πιθανότητα στο Control Panel να βλέπεις GREEK σε Location & Administrative - Language for non-Unicode Programs αλλά τελικά το Default Language του Operating System να  είναι  English .

Αν το Database Collation είναι Greek_CI_AS θα έπρεπε να δουλεύει ....

Αρα σου προτείνω να ελέγχεις τα παρακάτω

1) Εχεις ελέγχει όπως είπες το Regional and Languages - Location και το Αdministrative Language for non-Unicode Programs στο Control Panel και είναι και τα 2 GREECE

2) Open registry και πηγαινε στο  HKEY_USERS\.DEFAULT\Control Panel\International αν εκεί βλέπεις  Language LocaleName EN-US  sCountry United States τότε συμβαίνει αυτο που σου λέω.

3) Παρε backup το  HKEY_USERS\.DEFAULT\      ( export δηλαδη σε file το key)

4) Αλλαξε τις τιμες στο παραπάνω key με τις τιμές που προφανώς έχεις σωστά στο αντιστοιχο key του Default Administrator του Server το οποιο είναι  στο HKEY_USERS\S-1-5-21-xxxxxxxxx-xxxxxx-xxxxxxx-xxxx\Control Panel\International

5) Reboot τον Server

Link to comment
Share on other sites

Το θέμα δεν είναι ο sql server. Είναι οι εφαρμογές και ο τρόπος που φέρνουν τα δεδομένα. Εαν οι εφαρμογές ήταν ενσωματωμένες και έτρεχαν μέσα από τον Sql server τότε δε θα υπήρχε πρόβλημα. Το πρόγραμμα της Epsilon, Singularlogic κα είναι .Net ή Delphi ή xxxx εφαρμογές. Ο τρόπος που φτιάχνουν το connection string βασίζεται και στα regional settings του λειτουργικού. Είτε Latin1 είναι ο server και η βάση σου είτε Greek μέσα απο τον SQL server πάντα βλέπεις Ελληνικά. Για άνοιξε ένα Control της Singularlogic και δες τα δεδομένα?

Link to comment
Share on other sites

Το connection string δεν λεει τίποτα περισσότερο από οδηγίες για το πως θα φτάσει η εφαρμογή στην πηγή για να πιεί νερό. Από εκει και πέρα είναι καθαρά τι έχεις γράψει στον κώδικα.

Αλλά θα το πως για πολλοστή φορά.

Δεν χρειάζεται να κάνεις τίποτα περισσότερο από το να γράψεις απλό κώδικα για να έχεις όμορφα και ωραία ελληνικά με τον SQL Server.

Τουλάχιστον η ταπεινή μου εμπειρία στα 23 χρόνια που γράφω κώδικα αυτή είναι και με έργα τα οποία έχουν παίξει σε όλα τα μήκη και πλάτη της γης αυτής που πατούμε.

Link to comment
Share on other sites

Καλημέρα

Σε καμία περίπτωση δεν χρειάζεται να κάνεις όλα αυτά για να στήσεις SQL Server για να έχεις ελληνικά.-

Aντώνη συμφωνώ απόλυτα μαζί σου .Αλλά προφανώς δεν έγινα πολυ κατανοητος στο παραπάνω post μου ...θα το αναλύσω περαιτέρω ...

Οπως αναφέρω εφόσον η DB έχει GREEK_CI_AS collation σημαίνει ότι δεν έχει πρόβλημα με τα Ελληνικα.

Αρα δεν παίζει σημασια αν ο SQL ώς instance έχει collation Latin1.

Για αυτό το λόγο σου δίνει το δικάιωμα να αλλάξει collation σε επίπεδο DBs ..μπορεις να έχει μία DB με ελληνικα ,μια κινεζικη και μια αραβική... [:)]

Εκανα απλά μια διαπίστωση στο παραπάνω post και αυτή ήταν η εξής ...Για να πάρει collation Latin1 ο SQL κατά την εγακτάσταση του το Windows 2008 είχε locale US και όχι GREEK

Που διαφοροποιείτε η εγκατάσταση της εφαρμογης πριν και μετα το migration ?
Στο Collation της SQL Database ? OXI κατηγορηματικά αφου και οι 2 DBs ( πριν & μετα) εχουν collation GREEK_CI_AS

Αρα αν το locale και των 2 servers που ήταν η εφαρμογη είναι σίγουρα GREEK τότε έχουμε πρόβλημα στην εφαρμογή ....

Αν τώρα λόγω τις διαδικασίας που ακολουθήθηκε στην  εγκατάσταση του OS στο νέο server (αρχικά default installation με locale US - μετα εγκατάσταση SQL και μετα αλλάγη σε Windows σε locale GREEK)

μπορεί να μην έχει αλλάξει το HKEY_USERS\.DEFAULT key τα Regional Settings με αποτέλεσμα ναι μεν στο Control Panel να βλέπεις GREEK αλλα η εφαρμογή να βλέπει English locale στον server λόγω του .Default\International

Αρά η διαπίστωση είναι ...ΔΕΝ ΦΤΑΙΕ Ο SQL εφοσον τα collation  της DB είναι σωστά .... ποια η διαφορά με την  αρχικά εγκατάσταση ?

τα Locale του OS ... και η δοκιμή που προτείνω είναι απλή και με rollback ...

Kαι συμφωνώ με όλους για τις προβήματικές εφαρμογές με των κώδικα & unicode κτλ ...

Υπο K.Σ συμφωνώ ότι πχ αν έχει κώδικα σωστό η εφαρνογή δεν συνδέετε άμέσα με το Locale του OS .Aλλά οι περισότερες εφαρμογές ASP.NET πx Currency Tme Date δεν τα έχουν σαφώς προκαθορισμένα με αποτέλεσμα να πετάνε ότι βλέπουν από locale OS

 

Link to comment
Share on other sites

 Share

×
×
  • Create New...