Καλησπέρα,

Έχω διαπιστώσει ότι διαφορετικά συμπεριφέρεται ο OLEDB data provider και ο Oracle data provider που δίνει η Oracle στην αποθήκευση χαρακτήρων στην Oracle. Πολύ γενικά, εξαρτάται από τις ρυθμίσεις που έχει ο χρήστης στη registry και συγκεκριμένα στο NLS_Lang. Ο Τοαd και ο PLSQL developr όταν έχουμε NLS_LANG ISO-8859 στο registry και έχουμε βάση με ISO-8859 επίσης, δεν αποθηκεύει χαρακτήρες σε ΙSO αλλά σε ΜSWIN κωδικοποίηση. Δοκιμάστε να αποθηκεύσετε το γράμμα Ά (Α τόνος).  Το ερώτημά μου είναι

ποιοι εκτυπώσιμοι χαρακτήρες διαφέρουν μεταξύ ISO 8859 και MSWIN 1253;

ευχαριστώ θερμά

Θα λύσεις το πρόβλημα σου, και άλλα που μπορεί να προκύψουν στο μέλλον, αν χρησιμοποιείς πεδία nvarchar αντί για varchar. Για την περίεργη συμπεριφορά του Oracle Client σε multilingual περιβάλλον έχουμε ξανακουβεντιάσει. Το λιγότερο είναι ότι δεν λαμβάνει υπόψη τη γλώσσα του λειτουργικού ή του χρήστη και χρησιμοποιεί μόνο τη γλώσσα που έχει οριστεί στο registry. Μάντεψε λοιπόν, ελληνικό registry, αγγλικά Windows, καλημέρα σας!

Όσο μικρότερη εξάρτηση έχεις από τη γλώσσα ενός string τόσο διευκολύνεται η ζωή σου. Παρεμπιπτόντως, ρίξε μία ματιά στον Oracle Driver της Core Labs. Δεν απαιτεί Oracle Client, οπότε γλυτώνεις τα 80+ MB που απαιτούνται, είναι πολύ γρήγορος, αλλά δεν είναι και τσάμπα.

Υ.Γ. Αλλά να έχει και ο PL/SQL developer πρόβλημα? Αυτό δεν το περίμενα.

Βρε καλώς τον!

Δεν είμαι σίγουρος αν έχω απάντηση, αλλά είπα να σε καλοσωρίσω!

Κατά τα άλλα νομίζω ότι η μοναδική διαφορά (εφόσον μιλάμε για εκτυπώσιμους χαρακτήρες) είναι αυτή με το τονισμένο Α.

Dimitris Papadimitriou Software Development Professional

Ευχαριστώ Δημήτρη,

Είναι και το σύμβολο του ευρώ €.

O Microsoft OLD Provider for Oracle κοιτάει registry settings οπότε δεν κάνει transformation εάν η registry και η βάση έχουν NLS_LANG AMERICAN_AMERICA.EL8ISO8859P7. Οπότε το Ά αποθηκεύεται σαν 162 ASCII(MSWIN Greek) και όχι ως 182(ISO). Έχω γράψει και στο MSDN http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1488682&SiteID=1

AMERICAN_AMERICA και ελληνικό codepage? Αχ, έχω περάσει και από τέτοια κατάσταση, η οποία μας είχε δημουργήσει τα άπειρα προβλήματα. Το χειρότερο απ' όλα ήταν ότι δεν ήξερες ποτέ τί θα σου γυρίσει σαν δεκαδικό, η τελεία ή το κόμμα. Υπήρχε ένα κάρο προβληματικός κώδικας ο οποίος προσπαθούσε να αλλάξει το ένα με το άλλο, και δεν δούλευε ποτέ. Πήρε πολύ καιρό στους παλιούς developers (οι οποίοι είχαν γράψει όλο αυτό τον κώδικα) να καταλάβουν ότι η αιτία του προβλήματος ήταν αυτό το AMERICAN_AMERICA σε ελληνικό μηχάνημα! Όταν το γυρίσαμε σε απλό και άδολο GREEK_GREECE και Unicode, και αφαιρέσαμε όλο τον κώδικα για τις άχρηστες μετατροπές μεταξύ ελληνικών και αγγλικών αριθμών, όλα δούλεψαν πολύ ωραία.

Βέβαια, αυτό δεν συγκρίνεται με την ομάδα που έκανε το ίδιο στον SQL Server! Ο οποίος κάνει αυτόματη μετατροπή μεταξύ των locales! Εκεί να δεις κώδικα, για να ξαναμαναμετατρέψεις την τιμή την οποία ήδη είχε μετατρέψει ο SQL Server.

Το σύμβολο του ευρώ πάντως προστέθηκε αρκετά μετά το ISO 8859, καθότι δεν υπήρχε ευρώ όταν δημιουργήθηκε το ISO 8859. Οπότε υποθέτω ότι το EL8ISO8859 δεν είναι πλέον και τόσο στανταρ όσο λέει το όνομα του.

Δημήτρη, η λύση που προτείνεις στο MSDN είναι η αιτία του προβλήματος που με είχε βασανίσει στο παρελθόν. Δεν υπάρχει λόγος να δουλεύει κανείς με ASCII χαρακτήρες και οπωσδήποτε δεν υπάρχει λόγος να λες στην Oracle ότι το ελληνικό μηχάνημα βρίσκεται στην Αμερική.

  Γειά σου Δημήτρη, δεν ξέρω αν έλαβες καμιά απάντηση στο πρόβλημα το οποίο το είχα και εγώ όπως μπορείς να δεις στην συζήτηση που είχα ανοίξει στο DOTNETZONE. Επίσης είχα ανοίξη και case στην Microsoft και η απάντηση που έλαβα ήταν η παρακάτω:

I would need to reproduce your issue in order to understand it correctly, but it will take me time to find an Oracle server with the same settings and build a .Net application inserting Greek characters.
I would like to suggest the solutions that should help in your case:
- Change the CharacterSet of the Oracle database from P1 to P8 – but you told me it’s not possible.
- Use the Oracle .Net Managed Provider provided by Oracle.
This provider should have the same functionality than the Microsoft one (System.Data.OracleClient) but has been built by Oracle.
So you should expect it to have a better compatibility with the CharacterSet. Please download it from: http://www.oracle.com/technology/tech/windows/odpnet/index.html
- Use the OLEDB .Net Managed Provider, with the OLEDB Provider for Oracle (Microsoft’s one MSDAORA or Oracle’s one ORAOLEDB).
Be aware that the native OLEDB providers do not support Unicode (http://support.microsoft.com/?id=244661).
But by setting the NLS_LANG registry key to be the same as the Oracle Database CharacterSet, there is no conversion and the data should be displayed correctly.
à Open Regedit.exe on the Client machine, and go to HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE.
You should find a NLS_LANG key à please make it match the Oracle Database CharacterSet – then restart the machine.
- Last, give a try to the Merant .Net Managed Provider http://www.datadirect.com/products/net/netrelhighlights/index.ssp
Also, how do you insert the data in the Oracle database?
Are you using a .Net application? A Third-party tool?
Are you sure it’s being stored correctly in the database?

If you want to test the characters, you can use this kind of converter: http://www.macchiato.com/unicode/convert.html
If it’s not well-displayed with the .Net Managed Providers (Microsoft and Oracle’s ones) or the OLEDB Providers, then the data is likely to be incorrectly stored in the database… and in this case, then you will have to change the Database CharacterSet. 

Νομίζω ότι στο Link του MSDN γράφω αναλυτικά για το παραπάνω  issue και βλέπω ότι και η Microsoft συνοπτικά λέει το ίδιο.

Απλά ο  OLEDB .Net Managed Provider είναι πολύ αργός και δεν ενδείκνυται για καμία λειτουργία.

Το θέμα είναι πως με OLEDB provider εχοντας στο regisrty τα ίδια setting με της βάσης, ναι μεν δεν κάνει conversion αλλά αποθηκεύει τους χαρακτήρες  που πληκτρολογεί ο χρήστης στην εφαρμογή του σαν MSWIN για βάση που έχει ρυθμίσεις ISO 8859.

Δοκιμασέ το.

Ευχαριστώ θερμά.

Που την ξαναθυμηθήκατε αυτή τη συζήτηση! Πάντως δεν έχει νόημα να ανοίγετε cases στη Microsoft για κάτι που είναι απλά η περίεργη συμπεριφορά της Oracle όσον αφορά την υποστήριξη γλωσσών. Η Oracle έχει την παραξενιά ότι αγνοεί τη γλώσσα του χρήστη και βασίζεται στα NLS_LANG settings. Δεν ξέρω αν άλλαξε συμπεριφορά στους τελευταίους driver, αλλά αμφιβάλλω. Η συμπεριφορά αυτή οφείλεται στο Oracle Client και όχι στον OLEDB ή τον .NET driver. Τα settings επηρεάζουν και τους Microsoft drivers και τους JDBC drivers, οπότε δεν νομίζω να έχει αλλάξει.
Η λύση είναι απλά ... δεν χρησιμοποιούμε VARCHAR αλλά NVARCHAR. Διαφορετικά, προσαρμοζόμαστε εμείς στις παραξενιές της Oracle.

Πάντως, ρίξτε και μία ματιά στους drivers της CoreLabs. Είναι πολύ γρήγοροι, ΔΕΝ χρειάζονται Oracle Client (γλυτώνουμε έτσι καμμιά 100αριά MB από το setup!) και υποστηρίζουν το provider model του ADO.NET 2.0. Η ίδια εταιρεία βγάζει και αντίστοιχους driver για MySQL.