Come molti sanno, dalla versione Mango di WP7 è possibile utilizzare il database SQL Compact 3.5 (WP7 Edition) per gestire database locali alle applicazione WP7.
Poiché il motore ORM è LinqToSQL, è opportuno ricordare che esiste una tabella di mapping che associa i tipi SQL Compact 3.5 agli equivalenti tipi CLR:

Occhio alla nota relativa al SQL Decimal data type!
E poiché è ipotizzabile un collegamento a SQL Azure per sincronizzare i nostri dati locali con un database in the cloud, è opportuno ricordare che esiste anche una tabella di mapping tra tipi SQL di SQL Server e SQL Compact:

Seguite il link per l’elenco completo.
E infine, è importante ricordare che esiste una tabella di mapping che ben illustra ciò che accade ai dati nel passaggio bidirezionale tra i dati di SQL Server e i dati CLR:

Da cui si ricava che i tipi di dati che subiscono problemi di “overflow” o “data loss” e che quindi è meglio non usare sono:
SQL | |
DECIMAL(n) | |
CHAR(n), NCHAR(n) | a meno che n non sia pari a 1 |
VARCHAR(n) e NVARCHAR(n) | a meno che n non sia uguale a MAX |
SMALLDATETIME, DATETIME, TIME | usare sempre DATE o DATETIME2 |
BINARY(n), VARBINARY(n) | usare sempre VARBINARY(MAX) |
TIMESTAMP | |
| |
CLR | |
SByte, UInt16, UInt32, UInt64, Decimal, Enum, TimeSpan, ISerializable | |
Spesso queste informazioni si danno per scontate o sono prese sottogamba, perché tanto “ci pensa il framework”, ma uomo avvisato mezzo salvato, ed io per primo!
posted @ domenica 6 novembre 2011 19:31