MS SQL Server
  1. MS SQL Server
  3. Recommandations sur l'utilisation de SQL Server GUID à partir de MS Access
Intereting Posts
Différence entre deux lignes avec date dans l'ordre croissant API de schéma de database Ajouter des expressions Excel à un résultat de requête SQL Comment puis-je éviter une exception java.sql.SQLException due à une erreur d'E / S: la réinitialisation de la connection? Cas TSQL dans l'instruction where si le paramètre est null Identifier les dependencies au niveau des colonnes entre les bases de données SQL Server Raiserror ne provoque pas d'exception dans le client .NET Prendre la deuxième rangée en dernier avec un seul choix dans SQL Server? Ms SQL geography.STDistance return erroné distance Manière la plus rapide d'insert 100 000 loggings dans SQL Server SQL sortinggger découpe email après @ Sélectionnez la taille de la database SQL Server Exclure les lignes d'une requête SQL en fonction du nombre de lignes dans lesquelles un ID est présent Comment: configurer IIS7 pour la synchronisation Web python odbc Erreur lors de l'ouverture de la connection

Recommandations sur l'utilisation de SQL Server GUID à partir de MS Access

Je migre un backend MS Access existant vers SQL Server 2008 et, parce que nous voulons utiliser la réplication SQL Server Merge , je vais devoir changer toutes les keys primaires actuelles (actuellement des entiers auto-incrémentés standard) en GUID.

Alors voici les questions:

  • Toute recommandation sur faire le changement de keys primaires de l'entier à GUID?
  • Des recommandations sur l'utilisation et la manipulation du GUID à partir du code dans les clients Access?
  • Quel type de GUID SQL Server dois-je utiliser?

Chris a raison de dire que (1) vous n'avez pas besoin de GUIDS pour la réplication de fusion et (2) il n'y a qu'un seul type de GUID, mais vous devez savoir que:

  1. GUIDS peut être généré en suivant différentes règles. Vous pouvez vérifier ceci ici
  2. Lors de la définition d'une réplication, SQL appenda systématiquement un GUID (généré en tant que newsequentialid) à chaque table s'il n'existe pas déjà et l'appellera rowguid . Bien sûr, si vous avez déjà un GUID / newSequentialId dans chaque table, SQL l'utilisera. BUt Je ne vous conseille pas de 'mélanger' les GUID de réplication avec les GUID PK: vous pouvez déclarer toutes vos keys primaires du type GUID comme 'newSequentialIds', mais (a) vous perdriez alors la possibilité de générer des valeurs GUID du côté client – voir infra – et (b) vos PK seront alors 'prévisibles', et cette idée me met mal à l'aise …
  3. La conservation des entiers auto-incrémentés et la gestion de leur plage par la réplication impliquent de nombreux frais généraux (vous devez allouer des plages pour chaque table / chaque publication) et une source potentielle de conflits lors de la réplication à partir de différentes sources.
  4. De plus, certains bogues SQL comme celui-ci , spécifique à l'allocation de plages, ne sont toujours pas correctement résolus: l'application du pack cumulatif 5 n'a pas résolu notre problème et nous avons dû find un autre moyen de redémarrer nos process de réplication.
  5. Quoi qu'il en soit, je suis profondément convaincu qu'il est obligatoire de passer des entiers aux GUID en tant que keys primaires. Il y a de nombreuses raisons à cela, et l'une d'entre elles est liée à cette gestion de l'aire de répartition en tant que source potentielle de séances d'entraînement à la tête et au dépannage nocturne.

Concernant le passage des entiers au GUIDS, je vous conseille d'écrire un module étape par étape qui va:

  • Sauvegarde toutes les tables existantes avant de les modifier
  • Ajouter un champ GUID à chaque table
  • Ajouter les champs FK correspondants sur request
  • Mettre à jour les champs FK à l'aide de vues construites avec les relations existantes (construites sur des champs entiers)
  • Rompre les relations
  • Modifier les PK à partir des champs entiers dans les champs GUID
  • Recréer les relations

Prenez votre time pour écrire ce code. Vous l'utiliserez plusieurs fois avant de l'utiliser correctement. Vous devriez tirer profit de l'object DAO, tabledefs, index, et ainsi de suite. Gardez à l'esprit que vous devez toujours pouvoir revenir au sharepoint départ, alors n'oubliez pas le process de sauvegarde initial.

Qu'en est-il de la manipulation des GUID de VBA? Il y a quelques choses à savoir à ce sujet:

  • Les GUID sont du type Variant
  • Il est possible et facile de générer votre GUID en tant que key primaire du côté client de l'application, comme je l'ai proposé une fois ici .
  • Lorsque vous essayez d'get une valeur GUID à partir d'un contrôle dans un formulaire (généralement comme le champ lié dans une zone de list déroulante), vous obtiendrez '?????' mais aucune valeur. Vous devez vous référer à la valeur du champ dans le jeu d'loggings pour get datatables correctes. Vous pouvez ouvrir un tel formulaire dans votre application, allez dans la window 'immédiate', et essayez ceci: 
 ? myForm.myControl ????? ? myForm.recordset.fields("myFieldName") {000581EB-9CBF-418C-A2D9-5A7141A686CC}
  • Vous devrez peut-être convertir vos guids en strings lors de la navigation dans les jeux d'loggings avec des expressions telles que recordset.findfirst: 
 myFirstRecordset.FindFirst "ssortingngFromGUID(myGuidId) = " & SsortingngFromGUID(mySecondRecordset.Fields("myGuidId").Value)

Cela peut être légèrement hors sujet. Toutefois, vous n'avez pas besoin d'utiliser les GUID pour merge la réplication. Vous pouvez toujours utiliser vos entiers auto-incrémentés et allouer différentes plages à différentes instances de database. De cette façon, les lignes avec des ID identiques ne seront pas générées.

En outre, il existe un seul champ de type GUID dans SQL 2008 – uniqueidentifier