salve,
a.valandro wrote:

Salve a tutti, sono nuovo del forum e avrei un quesito da porvi. Mi trovo in questa situazione:
Devo spostare un'applicazione asp che gira su una macchina Win2k con SQL 2000 ad una 2k3 con SQL Express 2005.
Il problema è che questa applicazione è in bi-lingua, ita/russo. Sulla macchina 2000 nessun problema, i caratteri cirillici si vedono perfettamente e vengono salvati nel db altrettanto bene.
Una volta fatto il restore del db nella macchina 2003 e modificata la connessione nel Global.asa (cambiato solo il nome del server) nel nuovo server, i caratteri russi escono completamente sballati. Dopo svariare ricerche, sono riuscito almeno a capire che i caratteri che escono nell'applicazione sono codificati in UTF-8, e che per rivederli correttamente dovrei convertirli in Windows-1252. Ma se imposto il charset windows-1252 nell'applicazione (sia x l'html che per la parte asp) non ho nessun cambiamento.
Ho letto un pò in giro sulle differenze tra varchar o nvarchar e gli altri, sul collate (che però riguarda solo le regole di
interrogazione e ordinamento e non il charset).
Se guardo i dati nelle 2 consolle di sql, li vedo "sbagliati" in entrambe, e ho quindi dedotto che non dipende da sql ma
dall'applicazione. Ma se poi vado a inserire nuove righe (via applicazione) nel nuovo server, queste vengono salvate correttamente nel database.
A dire il vero vengono salvate correttamente se il campo è di uno di questi tipi (nvarchar o ntext).
Per favi un esempio di come escano i caratteri provo a postarvi una parola: Бежевое
che dovrebbe essere invece:
Бежевое
Grazie a chiunque mi possa aiutare.
Saluti, Federico.

relativamente a SQL Server, come gia' hai potuto verificate, i tipi di dato national supportano il formato unicode senza alcuna problematica... quindi ovviamente nel tuo caso devi utilizzare nchar ed nvarchar.. personalmente eviterei l'uso di ntext in quanto obsoleto, ed inoltre le funzionalita' di operazione su stringa sono disponibili solamente per
varchar/nvarchar/char/nchar, mentre per lavorare con i text/ntext si deve ricorrere a funzionalita' desuete di recupero di puntatori (textptr, ...).. relativamente alle regole di confronto, hai gia' verificato che queste vengono utilizzate per la validazione delle regole semantiche di ordinamento e confronto, quindi sono tecnicamente ininfluenti per l'archiviazione anche se ovviamente sono molto rilevanti per l'utilizzo dei dati stesso.. ti resta da verificare il character set utilizzato... se decidi di non utilizzare i tipi di dati national, devi impostare un character set che contenga tutti i caratteri (che identifica un "repertoire") utilizzati dalla lingua che andrai ad utilizzare... e' pero' anche importante che tutti i client remoti siano impostati a livello di localizzazione con le medesime impostazioni nazionali, in modo da avere consistenza tra i client ed il server... se ad esempio si inserisce il carattere dello yen giapponese tramite un client impostato con lo standard occidentale Windows character set, internamente SQL Server archivia un byte value (conosciuto anche "code point") uguale a 165 (0xA5). Se un'applicazione MS-DOS impostata con il codepage 437 recupera il valore, questo sara' mostrato come la N con la cidiglia sopra... in entrambi i casi il valore e' il medesimo, il codice 165, ma il Windows character set ed il codepage 437 MS-DOS lo mostreranno diversamente.. quindi, oltre a valutare le regole semantiche di confronto si deve anche valutare che i caratteri vengano mostrati come desiderato..
tornando ai tipi di dati national, questi invece utilizzano 2 byte per carattere, supportando pienamente il formato unicode.. resta il fatto che deve esserci consistenza di impostazione della nazionalizzazione tra i client remoti ed il server... di nuovo, se sul server con nazionalizzazione "russa" vedi correttamente i caratteri cirillici, su un client remoto con impostazione nazionale non conforme potresti vedere un insieme di "?????" o cose simili... vista la dicotomia tra alfabeto occidentale e cirillico, consiglierei l'utilizzo del tipo di dato national che, malgrado la richiesta di risorse esattemente doppia a livello di storage, ti consente di archiviare correttamente il valore alfabetico del dato senza la penalizzazione dell'impostazione di code page...
questo, a livello di SQL Server... per quanto riguarda "il resto", ti invito a verificare altrove le tue necessita' di impostazione a livello di singola macchina client.. ... devi in effetti ottenere omeneita' tra quello che il valore rappresenta e come viene renderizzato... questo perche' sicuramente e' archiviato correttamente, cosa che hai potuto verificare con mano.. saluti