Δες τη συζήτηση που έχει γίνει σε παρόμοιο πρόβλημα στο forum: "Ελληνικοί χαρακτήρες σε MSSQL ανεβασμένη σε hoster".

Νομίζω ότι πρέπει να έχει λύση στο πρόβλημά σου...

George J.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Δεν έχει νόημα να πειράζεις το collation, γιατί εφόσον οι χαρακτήρες είναι ήδη σε μορφή Unicode δεν επηρεάζονται από αυτό. Μέχρι και τη στιγμή που το κείμενο της σελίδας σου στέλνεται στον browser (αφού δηλαδή ολοκληρωθεί η εκτέλεση του κώδικα σου) τα δεδομένα είναι σε μορφή Unicode (UTF-16). Εκείνη τη στιγμή μετατρέπονται στο encoding που ορίζεται στο web.config. Το πρόβλημα βρίσκεται στις σελίδες σου. Είπες στην αρχή ότι στο web.config είναι ορισμένο UTF-8 ενώ στις σελίδες είναι ISO-8859-7 (υποθέτω ότι εννοείς στο αντίστοιχο meta tag έχεις βάλει ISO-8859-7) . To λιγότερο, θα πρέπει και οι σελίδες να γίνουν UTF-8.

Ρίξε πάντως μία ματιά στα δεδομένα της βάσης για να δεις σε τί μορφή είναι. Αν δεν εμφανίζονται σωστά ελληνικά υπάρχει η περίπτωση να έχουν καταστραφεί πριν καν αποθηκευτούν στη βάση. Αν για παράδειγμα τα στοιχεία εισάγονται από μία σελίδα η οποία έχει διαφορετικό codepage από αυτό που έχει οριστεί στο web.config μπορεί τα δεδομένα να φτάσουν κατεστραμμένα στη βάση. Το ίδιο επίσης μπορεί να συμβεί αν τα δεδομένα προέρχονται από άλλη βάση στην οποία υπήρχε λάθος collation (π.χ. ελληνικό κείμενο αποθηκευμένο σε βάση με Latin 1 collation).

Μαααααα .... η CreateObject και το ADODB.Connection δεν έχουν σχέση με το ADO.NET και την ASP.NET! Έχει σχέση με την ASP και το ADO, τεχνολογίες ξεχασμένες από το 2002!

Η CreateObject δημιουργεί ένα ActiveX αντικείμενο, στην περίπτωση σου το ADODB.Connection. Η κλάση αυτή καθώς και η ADODB.Command, ADODB.Recordset χρησιμοποιούνταν από την ASP και την VB6. Και αυτές υποστηρίζουν unicode, αλλά θέλουν περισσότερη προσοχή. Αν δούλευες σε VB6 πάλι δεν θα χρειαζόσουν να καρφώσεις πουθενά τη γλώσσα, στην περίπτωση σου όμως κάπου υπήρξε πρόβλημα κατά την μετατροπή από τον τύπο BSTR που χρησιμοποιεί το ADO σε .NET String. Τα πάντα εξαρτώνται από τον κώδικα που είχες γράψει (και δεν δίνεις εδώ).

Έχω μερικές παρατηρήσεις για τον κώδικα σου πάντως. Η ASP.NET είναι αρκετά διαφορετική από την PHP και παρακάμπτει πολλούς από τους περιορισμούς της. Θα πρέπει να μάθεις πως δουλεύει το ADO.NET και η ASP.NET πρώτα για να αποφύγεις κάποια συνηθισμένα λάθη.

• Καταρχήν, δεν χρειάζεται και ΔΕΝ ΠΡΕΠΕΙ να καρφώσεις το Connection String στον κώδικα σου. Είναι θέμα ασφάλειας αλλά και έτσι αποφεύγεις να ξανακάνεις compile τον κώδικα κάθε φορά που κάποιος αλλάζει το connection string. Κάθε web application έχει τα δικά του settings τα οποία αποθηκεύονται στο web.config. Στο Visual Studio τα βλέπεις μέσα κάνοντας δεξί κλίκ στο project σου και επιλέγοντας properties. Υπάρχει ειδικός τύπος setting για τα connection strings. Την τιμή των connection strings την βλέπεις πολύ εύκολα μέσω της global κλάσης Settings (στην C#, δεν θυμάμαι αν είναι η ίδια στην VB.NET).
• Καλύτερα να χρησιμοποιείς Integrated Security παρά sql username και password. Είναι πάλι θέμα ασφάλειας καθώς έτσι δεν χρειάζεται να αποθηκεύσεις πουθενά το password του connection. Θα πρέπει όμως να προσθέσεις το account του application pool του site σου στον SQL Server. Το default είναι το "Network Service".
• Αντί για χύμα SQL πρέπει να χρησιμοποιείς parameterized queries. Στην περίπτωση σου δεν περνάς καμμία παράμετρο, αλλά υποψιάζομαι ότι αν ήθελες να βάλεις ένα where θα το κόλλαγες απλά στο SQL string. ΚΑΚΟ. Κάτι τέτοιο θα σε άφηνε έκθετο σε SQL Injection attacks. Αν περνάς μία τιμή ως παράμετρο όμως ο κίνδυνος εξαφανίζεται. H PHP δεν υποστηρίζει parameterized queries, το ADO.NET όμως το επιτρέπει πολύ εύκολα. Και το παλιό ADO το επέτρεπε.
• Αντί να κλείνεις το reader και το connection με το χέρι μπορείς να χρησιμοποιήσεις το Using keyword για να κλείσουν αυτά αυτόματα, ακόμα και σε περίπτωση exception. Τώρα δεν έχεις κανένα exception handler, οπότε αν συμβεί κάτι περίεργο θα ξεμείνουν ανοιχτά τα connection, reader.
• Είναι προτιμότερο να φτιάχνεις σελίδες με code-behind κλάσεις παρά να ανακατεύεις στην ίδια σελίδα κώδικα και HTML. Τα πράγματα γίνονται πολύ πιο ξεκάθαρα έτσι.
• Αντί να γράφεις τις τιμές του DataReader μία-μία μπορείς να χρησιμοποιήσεις ένα DataGridView ή κάποιο άλλο databound control για να δείξεις απευθείας τα αποτελέσματα του query. Έτσι θα έχεις πολύ καλύτερο έλεγχο στην HTML που δημιουργείται απ' ότι τώρα, θα έχεις υποστήριξη για CSS και άλλα καλούδια. Τώρα, πρέπει να είσαι σίγουρος ότι δημιουργείς σωστό HTML. Χρησιμοποιώντας ένα έτοιμο control, αυτό το αναλαμβάνει το control.
  Για να δεις πως γίνεται αυτό, φτιάξε ένα Data Connection στη βάση σου από τον Server Explorer και τράβα τον πίνακα pages επάνω στη φόρμα σου. Το Visual Studio θα δημιουργήσει αυτόματα τις κατάλληλες κλάσεις για να δείξει τα περιεχόμενα του πίνακα. Θα δεις ότι ο κώδικας είναι πολύ λίγος.

Η ASP.NET δεν είναι PHP, έχει πολύ περισσότερες δυνατότητες. Θα πρέπει πρώτα να εξοικειωθείς με αυτή, και το ADO.NET πρωτού αρχίσεις να δουλεύεις με αυτή. Και "O SQL Server δεν θέλει κόλπα για να υποστηρίξει ελληνικά!"

Παναγιώτη σε ευχαριστώ για το αναλυτικό αυτό post.

Το θέμα είναι ότι δεν έχω προγραμματίσει εγώ αυτό το site, απλά έχω αναλάβει μόνο την μεταφορά του απο τον παλιό server σε έναν καινούριο.

Και απλά το πρόβλημα είναι η κωδικοποίηση των δεδωμένων από την db που φαίνεται χαλασμένη.

To site έχει ένα global.asa που εκεί υπάρχει το connection string και έχει ένα άλλο αρχείο στο οποίο φαίνεται να γίνεται όλη η δουλειά με την βάση.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 

<%
class RS_Data
    public pagesize
    public data
    public InitData
    public dataFields()
    public records
    public tot_Pages
    public Abs_Page
    public objConStr
    private objCon
    private objCmd
    public returnvalue
    private objRst
    private i
    private arrParams()
    private User_Name

    Private Sub Class_Initialize()
      pagesize = 10000
      Abs_Page=1
      objConStr=application("sql_connection_string")
      Set objCon = Server.CreateObject("ADODB.Connection")
      objCon.Open objConStr
      objCon.CommandTimeout=50
    End Sub

    public Function execSQL(sql)
          objCon.CommandTimeout=50
          Set objRst = Server.CreateObject("ADODB.Recordset")
          on error resume next
          objRst.Open sql,objCon,3,3
          if err.number <>0 then
          Response.Write sql
          Response.end
          end if
...

Αυτό το site παίζει μια χαρά στον παλιό server! Δεν έχω πειράξει τίποτε στον κώδικα.