Partager via

Mappage de types de données et éléments à prendre en compte

  • Article

Pour la synchronisation client et serveur, Sync Framework prend en charge les types de données serveur pouvant être mappés à des types de données valides dans SQL Server Compact 3.5 SP1 en utilisant ADO.NET. Les tableaux suivants décrivent comment les types sont mappés par défaut. Les deux premiers tableaux illustrent les mappages entre ADO.NET et SQL Server Compact. Le troisième tableau illustre les mappages entre SQL Server 2008 et SQL Server Compact. Ces mappages sont possibles, car ces deux versions de SQL Server partagent la plupart des mêmes types de données. Si une application nécessite différents mappages, utilisez l'objet SyncSchemaColumn pour mapper les types. Pour obtenir un exemple indiquant comment utiliser cet objet, consultez Procédure : initialiser la base de données client et travailler avec un schéma de table.

Mappages entre ADO.NET et SQL Server Compact

Type de données ADO.NET Type de données SQL Server Compact

Boolean

bit

Byte

tinyint

Byte[]

varbinary

Char

nchar

DateTime

datetime

Decimal

numeric

Double

float

Int16

smallint

Int32

int

Int64

bigint

SByte

tinyint

Single

real

String

ntext

UInt16

smallint

UInt32

int

UInt64

bigint
Type de données SQL Server Compact Type de données ADO.NET

bigint

Int64

binary

Byte[]

bit

Boolean

datetime

DateTime

float

Double

image

Byte[]

int

Int32

integer

Int32

money

Decimal

nchar

String

ntext

String

numeric

Decimal

nvarchar

String

real

Single

smallint

Int16

timestamp

Byte[]

tinyint

Byte

uniqueidentifier

Guid

varbinary

Byte[]

Mappages entre SQL Server 2008 et SQL Server Compact 3.5

Type de données SQL Server 2008 Type de données SQL Server Compact 3.5 SP 1

bigint

bigint

binary(n)

varbinary

bit

bit

char(n)

nchar(n) ou ntext

Si la longueur des données est inférieure ou égale à 4 000 caractères, nchar est utilisé ; sinon, ntext est utilisé.

Type CLR défini par l'utilisateur

Non pris en charge.

date

Valeur nchar(27) de la forme « AAAA-MM-JJ » 1

datetime

datetime

datetime2

Valeur nchar(27) de la forme « AAAA-MM-JJ hh:mm:ss.nnnnnnn » 1

datetimeoffset

Valeur nvarchar(34) de la forme « AAAA-MM-JJ hh:mm:ss.nnnnnnn [+/-] hh:mm » 1, 2

decimal

Non pris en charge ; utilisez numeric.

double

double

float

float

geography

Non converti par Sync Framework 3

geometry

Non converti par Sync Framework 3

hierarchyid

Non converti par Sync Framework 3

image

image

int

int

money

money

nchar(n)

nchar(n)

ntext

ntext

nvarchar(n)

nvarchar(n)

nvarchar(max)

ntext

Si la longueur des données dépasse la longueur de la colonne ntext, la synchronisation échoue.

numeric

numeric

real

real

smalldatetime

datetime

Si la précision des données datetime dépasse la précision de la colonne smalldatetime, la synchronisation échoue.

smallint

smallint

smallmoney

money

sql_variant

ntext

Si des données binaires existent dans la colonne sql_variant , elles doivent comprendre un nombre d'octets pair ou une erreur de conversion se produit.

text

ntext

Si la longueur des données de texte dépasse 1 073 741 823 caractères, la synchronisation échoue.

time

Valeur nvarchar(16) de la forme « hh:mm:ss.nnnnnnn » 1

tinyint

tinyint

uniqueidentifier

uniqueidentifier

varbinary(n)

varbinary(n)

varbinary(max)

image

Si la longueur des données dépasse la longueur de la colonne d'image, la synchronisation échoue.

varchar(n)

nvarchar(n) ou ntext

Si la longueur des données est inférieure ou égale à 4 000 caractères, nvarchar est utilisé ; sinon, ntext est utilisé.

varchar(max)

ntext

Si la longueur des données dépasse la longueur de la colonne ntext, la synchronisation échoue.

xml

ntext

1 Gardez à l'esprit les points suivants pour ces types de dates et d'heures :

  • Si le fournisseur serveur est hébergé sur un ordinateur qui exécute ADO.NET 2.0, ces types sont convertis sur le serveur. Si le fournisseur serveur est hébergé sur un ordinateur qui exécute ADO.NET 2.0 SP1, les types sont envoyés sur le client où ils sont convertis.

  • Les valeurs peuvent être traitées de façon différente sur le client et le serveur. Par exemple, avec une colonne de type datetime2 sur le serveur, les valeurs « 0001-01-01 00:00:00.0000000 » et « 0001-01-01 12:00 AM » sont identiques. Sur le client, les valeurs sont traitées comme des chaînes différentes. Les conséquences sont les suivantes :

    • Les colonnes de ces types ne doivent pas être utilisées dans les clés primaires.

    • Les colonnes de ces types doivent être traitées comme étant en lecture seule sur le client, sauf si une application garantit que la mise en forme des valeurs est contrôlée.

2 Si le fournisseur serveur est hébergé sur un ordinateur qui exécute ADO.NET 2.0 SP1, ADO.NET 2.0 SP1 doit également être disponible sur le client pour que la conversion réussisse. La conversion automatique de datetimeoffset sur le client n'est pas prise en charge par .NET Compact Framework 2.0 SP1 ni .NET Compact Framework 3.5.

3 Pour synchroniser ces types, vous pouvez les convertir en varbinary(max) ou image sur le serveur à l'aide de l'objet SyncSchemaColumn. Pour obtenir un exemple indiquant comment utiliser cet objet, consultez Procédure : initialiser la base de données client et travailler avec un schéma de table.

Considérations sur le mappage

Le comportement de Sync Framework est le suivant avec les types de données :

  • Les données des colonnes qui possèdent le type de données timestamp ne sont pas copiées à partir du serveur. Les colonnes timestamp sont mappées au type de données binary(8) durant la synchronisation. Cela est dû au fait que les données timestamp ne sont généralement explicites que dans la base de données dans laquelle elles ont été créées.

  • Les colonnes ROWGUID sont copiées du serveur vers la base de données client, mais la propriété ROWGUIDCOL de SQL Server n'est pas copiée. Pour obtenir un exemple décrivant comment définir cette propriété, consultez Procédure : initialiser la base de données client et travailler avec un schéma de table.

  • Les colonnes Compteur sont copiées du serveur vers la base de données client, mais les valeurs de début et d'incrément du compteur sont toujours définies à 0 et à 1, respectivement. Cela s'applique quelle que soit la manière dont les propriétés ont été définies dans la base de données serveur. Les colonnes d'identité de SQL Server Compact doivent posséder un type de données int ou bigint. Les colonnes d'identité de SQL Server Compact ne peuvent pas posséder un type de données smallint, tinyint, decimal ou numeric. Pour plus d'informations sur les colonnes Compteur, consultez Sélection d'une clé primaire appropriée pour un environnement distribué.

  • Les colonnes calculées sont copiées à partir de la base de données client durant le téléchargement, mais la propriété correspondante n'est pas copiée. Il est déconseillé d'utiliser les colonnes calculées dans les scénarios de synchronisation bidirectionnelle et par téléchargement ascendant, car les opérations d'insertion peuvent échouer lors du téléchargement. Pour éviter ce problème, filtrez les colonnes afin de ne pas les inclure dans la clause WHERE des instructions SELECT utilisées pour extraire les données. Pour plus d'informations sur le filtrage, consultez Procédure : filtrer des lignes et des colonnes.

Voir aussi

Concepts

Considérations sur la conception et le déploiement d'applications