Discussion :

[JYves]

Bonjour,

Je débute dans la Réplication et j'ai quelques questions pour peaufiner ma mise en oeuvre
Mon sujet : application C#, base de données SQL Server 2008R2 ou plus, que je souhaite partager sur des laptops d'utilisateurs qui feraient évoluer les données sans être connectés au serveur de Publication ni à internet et qui pourraient synchroniser de temps en temps (par exemple des commerciaux qui au retour de "missions", réinjectent les données modifiées dans la base de données du serveur de Publication).

Pour ce qui concerne les données SQL, je pense avoir cerné l'affaire (c'est très exagéré ) mais j'ai en parallèle des fichiers que je voudrais aussi synchroniser sans toutefois les inclure dans la base de données.
Il s'agit par exemple de fichiers .jpeg ou .tif

Dans mon idée, sur un serveur abonné, l'utilisateur stockerait dans un répertoire privé ces fichiers et, manuellement (clic sur un bouton dans l'application), transfererait ces fichiers vers un répertoire réseau public accessible à tous les serveurs (publication et abonné).
Un utilisateur connecté au serveur de Publication choisirait lui (idem via un bouton dans l'application) de "traiter" ces nouveaux fichiers reçus dans ce répertoire réseau public.

Pour mettre en place cette idée, je pense qu'il me faudrait accéder dans mon application C# à des informations telles que :

• Suis-je un utilisateur connecté sur un serveur Abonné ou s'agit-il du serveur de Publication ? (peut-on par exemple le détecter à l'aide d'une requête SQL ?)
• Si je suis sur un serveur Abonné, puis-je me synchroniser ? (c'est à dire la connexion est-elle possible avec le serveur de Publication ou suis-je en mode "déconnecté" ?)

Je me doute que ces questions sont un peu "bancales" (voire pire , peut-être fais-je totalement fausse route ), mais je suis preneur de vos remarques/idées/conseils/expérience.

Merci d'avance,
JYves

[JYves]

Hello,

Mon problème est-il si incongru ?
Sinon, peut-être pourriez-vous m'aiguiller vers un autre forum ou site spécialisé dans la réplication (français ou anglais) où je pourrais poser mon problème ?

Merci d'avance,
JYves

[SQLpro]

C'est surtout pas du tout clair. Vous mélangez des traitement qui n'ont rien à voir avec de la réplication et la réplication de données intégrée à SQL Server.

Si vous commenciez par le commencement en spécifiant votre besoin plutôt qu'une solution on pourrait vous aiguiller sur la meilleure solution...

A +

[JYves]

Bonjour,

Merci de votre réponse, je vais essayer d'être plus clair

• J'ai une application C# client lourd, progiciel.
• tous les utilisateurs accèdent à une base de données SQL Server 2008R2 ou plus.
• une évolution prévue de mon application est que certains utilisateurs (laptops) puisssent l'utiliser temporairement sans pour autant être connectés au réseau (et donc pas d'accès à la base de données non plus).
• pour cette utilisation "déconnectée", la réplication me semble un bon choix.
• j'ai choisi la réplication de fusion car les données peuvent évoluer sur tous les postes des utilisateurs ("connecté" ou "non connecté").
• je n'ai pour l'instant pas de problème avec la réplication des données (mais je débute seulement les tests).
• Par contre, mon application permet aux utilisateurs de "lier" des photos à des données SQL: ce "lien" consiste à renseigner dans un champ varchar d'une table l'UNC de la photo. (IRL, l'utilisateur prend une photo dans la nature avec son APN, il stocke la photo sur son disque dur et dans l'application indique le lien UNC sur la table adéquate).
• c'est là qu'est mon problème, quand l'utilisateur est dans la nature il est en mode "non connecté", le stockage des photos ne va pas se faire sur le réseau et je cherche donc une solution pour transférer ces photos (et modifier les liens UNC stockés en base de données) sur le réseau lorsque l'utilisateur va passer du mode "non connecté" au mode "connecté"

Je ne sais pas si c'est plus clair mais j'ai essayé

JYves

[SQLpro]

'ai choisi la réplication de fusion car les données peuvent évoluer sur tous les postes des utilisateurs ("connecté" ou "non connecté").

ATTENTION : prévoyez de résoudre les conflits de réplication sinon vous allez au devant de gros ennuis. Personnellement j'évite ce genre de réplication qui n'est généralement pas indispensable au profit de la réplication transactionnelle, seule apte à garantir l'intégrité logique des données.

Par contre, mon application permet aux utilisateurs de "lier" des photos à des données SQL: ce "lien" consiste à renseigner dans un champ varchar d'une table l'UNC de la photo. (IRL, l'utilisateur prend une photo dans la nature avec son APN, il stocke la photo sur son disque dur et dans l'application indique le lien UNC sur la table adéquate).

Pourquoi utiliser une solution aussi bourrin ? par masochismes ? Alors que vous pouvez au choix :
1) mettre les photos dans des LOBs (type VARCHAR(max)) dans une table ou ils seront répliqués comme toute autre info
2) utiliser un stockage FILESTREAM qui permet de stocker des fichiers sous le contrôle du serveur SQL. Ils seront aussi répliqués
https://msdn.microsoft.com/fr-fr/lib...px#Replication
3) utiliser une "filetable", même principe que le FILESTREAM, mais en plus générique

[*]c'est là qu'est mon problème, quand l'utilisateur est dans la nature il est en mode "non connecté", le stockage des photos ne va pas se faire sur le réseau et je cherche donc une solution pour transférer ces photos (et modifier les liens UNC stockés en base de données) sur le réseau lorsque l'utilisateur va passer du mode "non connecté" au mode "connecté"

Cette solution n'est pas viable, parce que pas intègre !

A +

[JYves]

Bonjour,

Merci beaucoup de votre réponse détaillée
Je vais étudier vos propositions en détail et je reprendrai la discussion ensuite.

JYves

[JYves]

ATTENTION : prévoyez de résoudre les conflits de réplication sinon vous allez au devant de gros ennuis. Personnellement j'évite ce genre de réplication qui n'est généralement pas indispensable au profit de la réplication transactionnelle, seule apte à garantir l'intégrité logique des données.

J'ai reconsidéré mon choix à la lecture de votre avertissement.
J'ai relu quelques documentations dont j'extrais ici quelques contraintes qui impactent mon choix de type de réplication :

• Réplication transactionnelle standard : toutes les données de l'Abonné sont en lecture seule => NOK pour mon projet.
• Réplication transactionnelle d'égal à égal : disponible uniquement dans les versions Enterprise de SQL Server => NOK pour mon projet, contrainte financière, les abonnés utiliseront des versions gratuites SQL Express.
• Réplication de fusion : "des abonnés doivent recevoir des données, apporter des modifications hors connexion et synchroniser ultérieurement ces modifications avec l'éditeur et d'autres abonnés" => OK, ça correspond exactement à mon projet.

Je ne vois donc pas comment éviter la réplication de fusion
Je n'avais pas prévu de gérer les conflits de réplication. Je pensais naïvement les laisser gérer par le serveur de publication. Il faudra que je me replonge là-dessus.
Peut-être avez-vous des conseils quant à la gestion de ces conflits ou d'autres suggestions pour le type de réplication ?

Je vais étudier vos propositions de stockage (BLOB, FILESTREAM, filetable) pour les images.

Merci,
JYves

[SQLpro]

Relisez beaucoup plus attentivement... Parce que je sias pas ou vous avez péché cela, mais c'est faux !

J'ai reconsidéré mon choix à la lecture de votre avertissement.
J'ai relu quelques documentations dont j'extrais ici quelques contraintes qui impactent mon choix de type de réplication :

Réplication transactionnelle standard[/B] : toutes les données de l'Abonné sont en lecture seule

Absolument faux. Les données peuvent être mise à jour, mais :
1) la mise à jour des données de l'abonné ne se répercute pas sur la base de publication
2) la diffusion des mises à jour de données depuis la base de publication va écraser les mises à jour fait sur l'abonné.
Enfin, une réplication transactionnelle, ce n'est pas toutes les tables qui sont répliquées, mais des "articles", sous entendu un croisements de certaines lignes avec certaines colonnes.

Réplication transactionnelle d'égal à égal[/B] : disponible uniquement dans les versions Enterprise de SQL Server => NOK pour mon projet, contrainte financière, les abonnés utiliseront des versions gratuites SQL Express.
Réplication de fusion : "des abonnés doivent recevoir des données, apporter des modifications hors connexion et synchroniser ultérieurement ces modifications avec l'éditeur et d'autres abonnés" => OK, ça correspond exactement à mon projet.

ATTENTION : les agents de synchronisation n'étant pas automatisé (Agent SQL Server) il va vous falloir beaucoup de boulot pour orechestrer le tout...
https://technet.microsoft.com/fr-fr/...QL.105%29.aspx

Je ne vois donc pas comment éviter la réplication de fusion

Il suffit que les flux ne soient pas les mêmes.
Par exemple si appli commerciale :
table "Produit" réplication du serveur central aux serveurs locaux
table "commande" réplication des serveurs locaux vers le serveur central.

Je n'avais pas prévu de gérer les conflits de réplication. Je pensais naïvement les laisser gérer par le serveur de publication. Il faudra que je me replonge là-dessus.

Il faut créer des déclencheurs sur chaque table pour appliquer la règle d'entreprise; par exemple, c'est toujours le serveur central qui gagne...

Peut-être avez-vous des conseils quant à la gestion de ces conflits ou d'autres suggestions pour le type de réplication ?

Je vais étudier vos propositions de stockage (BLOB, FILESTREAM, filetable) pour les images.

Merci,
JYves

A +

[JYves]

Bonjour,

Merci beaucoup pour votre réponse détaillée !

Relisez beaucoup plus attentivement... Parce que je sias pas ou vous avez péché cela, mais c'est faux !

mes sources : MSDN : https://msdn.microsoft.com/fr-fr/lib...ql.120%29.aspx où il est écrit "toutes les données de l'Abonné sont en lecture seule" dans la description du type Publication transactionnelle standard.


J'ai toutefois compris (il me semble en tout cas) vos préconisations.
Mais dans mon projet, il s'agit vraiment des mêmes fonctionnalités qui sont utilisées que ce soit sur un Abonné ou sur le serveur de Publication (il s'agit des mêmes utilisateurs de l'application). Les flux sont donc les mêmes.
C'est pourquoi je n'ai pas envisagé la publication ("partielle" ou "ciblée") d'articles mais plutôt la publication de toutes les tables de ma base de données (replication de fusion).

ATTENTION : les agents de synchronisation n'étant pas automatisé (Agent SQL Server) il va vous falloir beaucoup de boulot pour orechestrer le tout...
https://technet.microsoft.com/fr-fr/...QL.105%29.aspx

Je ne me rappelle pas avoir étudié ce problème des agents de synchronisation non présents sur le SQL Express, merci d'avoir pointé cette difficulté, je vais regarder ça de plus près !

Il faut créer des déclencheurs sur chaque table pour appliquer la règle d'entreprise; par exemple, c'est toujours le serveur central qui gagne...

Concernant les conflits, j'avais dans l'idée de généraliser le même traitement à tous les conflits : le serveur "gagne" ou "perd" systématiquement. Et comme j'ai un progiciel, éventuellement proposer un paramétrage.


Je suis aussi en train de regarder vos propositions de stockage (BLOB, FILESTREAM, filetable) pour les images, mais comme il s'agit d'une évolution de mon application et non de nouvelle installation, mes clients ont déjà parsemé leurs réseaux pour stocker leurs images. Il ne me semble pas possible de rapatrier lors d'une mise à jour leurs images en base de données (progiciel + de 500 clients, trop d'hétérogénéité).


Je patauge un peu
JYves

[SQLpro]

C'est pourquoi je n'ai pas envisagé la publication ("partielle" ou "ciblée") d'articles mais plutôt la publication de toutes les tables de ma base de données (replication de fusion).

Absolument pas tenable ni crédible !

En effet, si vous avez 500 postes nomades et qu'au pire ils se branche en même temps sur le serveur pour synchronisation des données des tables vous allez au plus avoir 500 versions de ligne par table.
En imaginant que cela se produise une fois par jour et que le volume des lignes modifiées par un utilisateur est juste de 100 (ce qui est peu) , vous allez potentiellement avoir : 6 250 000 conflits binaires à gérer par jour....
Un conflit => 2 lignes pour une même mise à jour cible

A +

[JYves]

Hum, j'ai l'impression que la réplication de fusion n'a pas vos faveurs

Mon projet est bien plus humble quant au nombre de postes nomades : un ou deux, quatre au maximum !
Ma base de données est très petite aussi, moins de 10 Go (SQL Express sur les postes nomades).
Pour ce qui concerne le nombre de lignes modifiées, à priori ce ne seront pas les mêmes côté serveur de publication et postes nomades ce qui réduit considérablement, à mon avis, le nombre de conflits potentiels lors des synchronisation.
Par contre, je n'ai pas de délai de synchronisation fixe, un jour étant l'idéal mais je pense que ça pourra être plusieurs jours.

JYves

[SQLpro]

Hum, j'ai l'impression que la réplication de fusion n'a pas vos faveurs

C'est le moins que l'on puisse dire. En générale j’interviens en conseil à 1600 € / jour sur ce genre de sujet, car en général ceux qui ont des problèmes se sont généralement fourvoyés et en sus ont mis en place de telles mauvaises praitques, qu'il faut tout refaire !!! C'est le mode de réplication le plus complexe, entrainant le plus de consommation de ressources et pour lequel il faut en général un DBA à demeure...

Mon projet est bien plus humble quant au nombre de postes nomades : un ou deux, quatre au maximum !
Ma base de données est très petite aussi, moins de 10 Go (SQL Express sur les postes nomades).

Pour ce qui concerne le nombre de lignes modifiées, à priori ce ne seront pas les mêmes côté serveur de publication et postes nomades ce qui réduit considérablement, à mon avis, le nombre de conflits potentiels lors des synchronisation....

J'ai mis en gras le point clé que j'évoquais... Apparemment ce que vous dites c'est que vous ne modifiez pas les mêmes lignes au niveau du serveur et au niveau des postes nomades.
Si tel est le cas, la réplication de fusion n'est pas adaptée !

CQFD !

A +

[JYves]

Merci pour votre réponse.

Bon, je vais prendre un peu plus de temps pour lire les documentations
Je suppose cependant que vous m'aiguillez vers la réplication transactionnelle.

Mais au vu de contraintes que j'ai déjà évoquées :

• Réplication transactionnelle standard : toutes les données de l'Abonné sont en "lecture seule" = non renvoyées vers le serveur de distribution => NOK pour mon projet.
• Réplication transactionnelle d'égal à égal : disponible uniquement dans les versions Enterprise de SQL Server => NOK pour mon projet, contrainte financière, les abonnés utiliseront des versions gratuites SQL Express.

je ne vois pas trop comment m'y prendre.
D'autant que même si je pense que les données modifiées ne sont pas les mêmes côté Serveur de publication et côté Abonné, je ne sais pas à l'avance quels vont être les modifications/suppressions/ajouts

En générale j’interviens en conseil à 1600 € / jour sur ce genre de sujet, car en général ceux qui ont des problèmes se sont généralement fourvoyés et en sus ont mis en place de telles mauvaises praitques, qu'il faut tout refaire !!!

Pourquoi pas, c'est un budget mais comparé à une grosse erreur de stratégie, c'est peanuts

JYves

[SQLpro]

Mais au vu de contraintes que j'ai déjà évoquées :

Réplication transactionnelle standard : toutes les données de l'Abonné sont en "lecture seule" = non renvoyées vers le serveur de distribution => NOK pour mon projet.

Si le serveur central modifie la colonne A de la ligne 1, la colonne B de la ligne 2 n'étant pas répliquée,, elle peut être modifiée sans problème. Une publication est un croismeent de données et de lignes d'une table et il est même possible de répliquer l'exécution d'une procédure stockée...

Réplication transactionnelle d'égal à égal : disponible uniquement dans les versions Enterprise de SQL Server => NOK pour mon projet, contrainte financière, les abonnés utiliseront des versions gratuites SQL Express.

je ne vois pas trop comment m'y prendre.

Il suffit d'ientifier les éléments à prendre en compte en rajoutant des colonnes de métadonnées dans les tables. Par exemple le nom de la machine ou de l'utilisateur (voir les deux). Dès lors vos article répliqués ne prendraont en compte que les lignes propre à la machine et pas celle des autres...

D'autant que même si je pense que les données modifiées ne sont pas les mêmes côté Serveur de publication et côté Abonné, je ne sais pas à l'avance quels vont être les modifications/suppressions/ajouts


Pourquoi pas, c'est un budget mais comparé à une grosse erreur de stratégie, c'est peanuts

JYves

A +

[JYves]

Sans doute je fatigue en fin de semaine car j'ai du mal à vous suivre

J'ai bien compris qu'on pouvait filtrer les données (par ligne, par colonne) mais pour l'instant je ne vois pas trop ce que j'en ferais.
Ce filtrage me semble disponible pour tous les type de réplication (transactionnelle, fusion), mais j'en suis encore à choisir le type de transaction d'abord.

J'ai besoin que les données modifiées par l'Abonné puissent être renvoyées vers la base de publication.
Quel type de réplication puis-je utiliser (transtionnelle, fusion, ou une autre technique) sachant que les abonnés utiliseront des versions gratuites SQL Express.

JYves

[SQLpro]

Sans doute je fatigue en fin de semaine car j'ai du mal à vous suivre

J'ai bien compris qu'on pouvait filtrer les données (par ligne, par colonne) mais pour l'instant je ne vois pas trop ce que j'en ferais.
Ce filtrage me semble disponible pour tous les type de réplication (transactionnelle, fusion), mais j'en suis encore à choisir le type de transaction d'abord.

Pas du tout. C'est imposible dans la réplication SNAPSHOT et très limité dans la fusion.

J'ai besoin que les données modifiées par l'Abonné puissent être renvoyées vers la base de publication.
Quel type de réplication puis-je utiliser (transtionnelle, fusion, ou une autre technique) sachant que les abonnés utiliseront des versions gratuites SQL Express.

JYves

Le mieux est toujours transationnelle.

la question finale est la suivante :

Une même ligne dans une même table peut-elle :
1) être mise à jour dans le serveur central et être répliquée vers les postes satellite ?
2) cette même ligne de cette même table peut-elle aussi être mise à jour sur le poste v=client et renvoyée vers les serveur central ?

Si vous ne pouvez pas faire autrement, alors oui, il faut utiliser la réplication de fusion.

Sinon, la réplication transactionnelle marchera nettement mieux à tous les niveaux.

A +

[JYves]

Bonjour,

Merci de votre réponse !

Effectivement, dans mon projet, une même ligne peut être mise à jour sur le serveur central et être répliquée vers les postes satellites mais aussi être mise à jour sur un poste satellite et renvoyée ensuite vers le serveur central.
Ce n'est pas un cas particulièrement rare pour que je puisse demander au client de s'en passer donc la réplication de fusion est le bon choix pour mon projet.

J'avance !

Maintenant, il me faut trouver un moyen pour savoir si je suis en mode "connecté" ou "déconnecté" quand je suis sur un poste satellite.
Peut-être puis-je utiliser les RMO (Replication Management Objects) pour obtenir ce genre d'information ?

JYves

[SQLpro]

Maintenant, il me faut trouver un moyen pour savoir si je suis en mode "connecté" ou "déconnecté" quand je suis sur un poste satellite.
Peut-être puis-je utiliser les RMO (Replication Management Objects) pour obtenir ce genre d'information ?

Lisez attentivement ce document :
https://technet.microsoft.com/fr-fr/...ql.105%29.aspx

Entre autres prérequis, si vos insertions de nouvelles lignes peuvent se faire depuis différentes bases (entre les postes ou encore entre un des postes et le serveur), alors vous devez pensez au niveau des clefs autoincrémentées à les ventiler sur les différentes postes, sinon les conflits vont générer des violations de clef.
Par exemple si au maximum dans 15 ans, vous avez 100 postes, alors le premier commencera ses clefs autoincrémentées à 1 avec un pas de 100, le suivant à 2 avec un pas de 100, le 3e...

ATTENTION : ceci ne vous affranchira aucunement des conflits de réplication... Exemple :
Le poste 1 saisi le client Raoul Biscoteau de Neuvy sur Tombradour à 16h22
Le poste 2 saisi le client Raoul Biscoteau de Neuvy sur Tombradour à 16h22
Sont-ce les mêmes ?

Dans tous les cas, même avec avec un résolution de conflits intégrés il reste des zones d'ombre que seule une action manuelle peut permettre de résoudre. Et croyez moi, la mise à jour divergente d'une même information sur deux poste différents au même moment (à la milliseconde près) cela arrive TOUJOURS !

A +

[JYves]

Lisez attentivement ce document :
https://technet.microsoft.com/fr-fr/...ql.105%29.aspx

Merci, c'est très instructif !

Entre autres prérequis, si vos insertions de nouvelles lignes peuvent se faire depuis différentes bases (entre les postes ou encore entre un des postes et le serveur), alors vous devez pensez au niveau des clefs autoincrémentées à les ventiler sur les différentes postes, sinon les conflits vont générer des violations de clef.
Par exemple si au maximum dans 15 ans, vous avez 100 postes, alors le premier commencera ses clefs autoincrémentées à 1 avec un pas de 100, le suivant à 2 avec un pas de 100, le 3e...

J'utilise des ROWGUIDCOL pour garantir l'unicité de mes lignes et ceci dans toutes mes tables.

exemple de création d'une de mes tables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE [dbo].[MA_TABLE](
	[MA_TABLE_Id] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
        ...
        (autres propriétés)
        ...
	[_LastWriteTime] [datetime] NOT NULL CONSTRAINT [MA_TABLE_CONTRAINTE_LWT]  DEFAULT (getdate()),
	[_CreationTime] [datetime] NOT NULL CONSTRAINT [MA_TABLE_CONTRAINTE_CT]  DEFAULT (getdate()),
	[_LastWriteUser] [nvarchar](64) NOT NULL,
	[_CreationUser] [nvarchar](64) NOT NULL,
	[_rowVersion] [timestamp] NOT NULL,
 CONSTRAINT [PK_MA_TABLE_CONTRAINTE] PRIMARY KEY NONCLUSTERED 
(
	[MA_TABLE_Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

Sur mon serveur de publication, il n'y a pas d'incrémentation.
Par contre sur les abonnés, vous pensez qu'il peut y avoir un conflit si des lignes sont ajoutées car l'incrémentation va être la même à partir du dernier ID ?

ATTENTION : ceci ne vous affranchira aucunement des conflits de réplication... Exemple :
Le poste 1 saisi le client Raoul Biscoteau de Neuvy sur Tombradour à 16h22
Le poste 2 saisi le client Raoul Biscoteau de Neuvy sur Tombradour à 16h22
Sont-ce les mêmes ?

Clairement non pour mon projet. Les comparaisons se feront sur l'ID pas sur le texte ni l'heure.

Dans tous les cas, même avec avec un résolution de conflits intégrés il reste des zones d'ombre que seule une action manuelle peut permettre de résoudre. Et croyez moi, la mise à jour divergente d'une même information sur deux poste différents au même moment (à la milliseconde près) cela arrive TOUJOURS !

Je n'envisage pas d'action manuelle pour le moment mais je me laisse la porte ouverte ! Je pense améliorer cette partie des conflits si ça s'avère nécessaire à l'utilisation.

Merci de vos conseils éclairés,
JYves

[SQLpro]

Merci, c'est très instructif !

J'utilise des ROWGUIDCOL pour garantir l'unicité de mes lignes et ceci dans toutes mes tables.

Non, ça c'est catastrophique en terme de performances. Ne jamais utiliser les GUID comme clef primaire. De plus la réplication de fusion nécessite l'utilisation des GUID comme tag d'identification des lignes distribuées. Vous allez avoir de sérieux problèmes. Sachez que le mécanisme de calcul des GUID est un mécanisme de niveau Windows et que donc tous les accès concurrent pour insérer de nouvelles lignes vont taper dans le même bout de code, ce qui fait que cela constituera un hot spot indémerdable. De plus les GUID fragmentent les tables de manière catastrophique et vous allez donc passer votre vie à maintenir ces index !
Si vous voulez des performances, la seule chose est d'utiliser des auto incrément de type INT ou BIGINT.
Sachez que ROWGUIDCOL doit être réservé pour des traitements particulier comme le FILESTREAM. SI vous l'utilisez pour votre PK, vous ne pourrez plus utiliser le FILESTREAM !

Clairement non pour mon projet. Les comparaisons se feront sur l'ID pas sur le texte ni l'heure.

ça n'a pas de sens! En matière de BD on s'intéresse à la sémantique pas à des informations techniques. Qui vous dite que deux commerciaux ne saisiront pas le même client avec 2 id différents ?

Je n'envisage pas d'action manuelle pour le moment mais je me laisse la porte ouverte ! Je pense améliorer cette partie des conflits si ça s'avère nécessaire à l'utilisation.

La vous êtes cuit !

Merci de vos conseils éclairés,
JYves

A +