Présentation rapide de la mise à jour de données versionnées à l'aide de SQL

Pour mettre à jour des données versionnées à partir d'un client SQL, vous devez modifier une vue versionnée des données, pas la table de base (métier) elle-même. Les tables versionnées utilisent deux tables associées, les tables d'ajouts et de suppressions (collectivement connues sous le nom de tables des deltas), pour enregistrer les modifications. Lorsque vous mettez à jour une vue versionnée de la table, les mises à jour sont écrites dans les tables des ajouts et des suppressions. Le fait de mettre à jour directement la table de base contourne ce processus et peut causer des enregistrements orphelins et une perte de données.

Lorsque vous exécutez des instructions SQL de manipulation de données sur une vue versionnée, il se produit ce qui suit dans la base de données pour chaque type d'instruction : *

• Insertion : une ligne est ajoutée à la table des ajouts de la table de base sous-jacente et un identifiant d'objet est généré automatiquement pour le nouvel enregistrement.
• Mise à jour : la mise à jour supprime en fait l'enregistrement original et en ajoute un nouveau qui contient les nouvelles informations. Par conséquent, une ligne est ajoutée à la fois à la table des ajouts et à la table des suppressions de la table de base sous-jacente lorsque vous exécutez une instruction de mise à jour.
• Suppression : une ligne est ajoutée à la table des deltas de la table de base sous-jacente.

* Lors de la mise à jour de la version PAR DEFAUT pointant l'état 0, toutes les modifications sont déplacées immédiatement dans la table de base.

Notez qu'aucune réconciliation de versions interne n'est faite pour les mises à jour effectuées avec SQL. Par conséquent, vous devez rapprocher vos mises à jour avec une version parent via ArcGIS for Desktop ou un script Python lorsque vous avez terminé la mise à jour.

Méthodes de mise à jour

Vous pouvez créer une nouvelle version nommée de la géodatabase et mettre à jour cette version, ou vous pouvez mettre à jour la version PAR DEFAUT directement. La méthode choisie dépend des exigences de votre site. Il est important de choisir la méthode appropriée, mettre à jour une version nommée ou la version PAR DEFAUT, pour assurer performance optimale et évolutivité.

Mise à jour d'une version nommée

Il est préférable de créer et d'utiliser des versions nommées à mettre à jour avec SQL via des vues versionnées si l'une des conditions suivantes s'applique à votre site :

• Plusieurs éditeurs doivent modifier les mêmes données.
• Vous avez besoin d'un processus de contrôle de qualité bien défini.
• Il n'est pas nécessaire que les modifications soient immédiatement disponibles à d'autres utilisateurs ; elles peuvent être conservées à part jusqu'à ce que vous les rapprochiez et les publiez.
• Les classes d'entités versionnées que vous souhaitez modifier utilisent un type de stockage de géométrie binaire.
• La table ou la classe d'entités versionnée à mettre à jour est enregistrée comme versionnée avec l'option de déplacement des mises à jour dans la base.

Lorsque vous effectuez une mise à jour via vue versionnée, les modifications sont enregistrées dans les tables d'ajouts et de suppressions. Les mises à jour sont écrites dans l'état courant référencé par la version nommée.

Les étapes à suivre pour mettre à jour des données dans une version nommée sont présentées ci-dessous et doivent être effectuées dans l'ordre indiqué :

1. Créez une vue versionnée d'une table ou d'une classe d'entités versionnée, s'il n'en existe pas.
2. Créez une version de la géodatabase dans laquelle effectuer les mises à jour.
3. Utilisez la procédure set_current_version pour indiquer que vous désirez accéder à votre nouvelle version. La session de mise à jour est ainsi définie sur l'état pointé par la version nommée et verrouille la version.
4. Démarrez une session de mise à jour en exécutant la procédure edit_version ou la fonction appropriée à votre base de données.
5. Effectuez vos mises à jour sur la vue versionnée avec SQL.
6. Appliquez vos mises à jour à la base de données ou annulez-les.
7. Arrêtez la session de mise à jour en exécutant la procédure edit_version ou la fonction appropriée à votre base de données.
8. Réconciliez et réinjectez vos mises à jour par l'intermédiaire d'ArcGIS.
9. Une fois toutes les modifications réinjectées dans une version parent à l'aide d'ArcGIS, vous pouvez supprimer la version que vous avez créée pour vos mises à jour dans la vue versionnée.

Mise à jour de la version PAR DEFAUT

Vous pouvez modifier la version PAR DEFAUT avec SQL via des vues versionnées si une ou plusieurs des conditions suivantes s'appliquent à votre site :

• Les mises à jour à faire sont des transactions courtes.
• Votre site nécessite que les mises à jour effectuées via une vue versionnée soient immédiatement disponibles à d'autres utilisateurs.
• Lors de la mise à jour de classes d'entités, ces dernières utilisent des types spatiaux SQL, et non le stockage de géométrie binaire.
• La table ou la classe d'entités à mettre à jour n'est pas enregistrée comme versionnée avec l'option de déplacement des mises à jour dans la base.

Lorsque vous mettez à jour la version PAR DEFAUT, les modifications sont enregistrées dans les tables de deltas, comme lorsque vous modifiez une version nommée. Toutefois, lorsque vous mettez à jour la version PAR DEFAUT, les modifications peuvent être vues par toute personne qui affiche la version PAR DEFAUT.

Si la version PAR DEFAUT référence l'état 0, chaque modification est appliquée directement à la table de base de la table ou de la classe d'entités versionnée. Lorsque la version PAR DEFAUT est modifiée avec un client ArcGIS, la version est mise à jour pour référencer un nouvel état de base de données lors de l'enregistrement. Lorsqu'une vue versionnée modifie la version PAR DEFAUT directement, chaque opération d'insertion, de mise à jour et de suppression est écrite dans l'état courant référencé par la version PAR DEFAUT.

Par exemple, si la version PAR DEFAUT est mise à jour avec un client ArcGIS tandis que plusieurs changements sont opérés via la vue versionnée, il est possible que les changements réalisés par le biais de la vue versionnée puissent être appliqués à plusieurs états.

Une fois que vos mises à jour sont validées, elles sont immédiatement accessibles aux personnes/applications suivantes :

• Utilisateurs ou applications qui utilisent la table versionnée et la version PAR DEFAUT
• Utilisateurs ou applications qui utilisent une version enfant ayant une généalogie d'état qui contient l'état courant de la version PAR DEFAUT

Approfondissement :

Si l'enregistrement qui est modifié dans la version PAR DEFAUT par une vue versionnée a été modifié par une autre version dans un état dépendant de l'état courant de la version PAR DEFAUT, la vue versionnée crée un état de géodatabase, met à jour la version PAR DEFAUT afin de référencer le nouvel état, puis effectue la mise à jour. Cela est nécessaire pour assurer que l'enregistrement qui est modifié (lequel est également modifié dans un état dépendant de l'état de la version PAR DEFAUT) ne sera pas remplacé par une opération de compression ou lors du rapprochement de la version de l'état descendant avec la version PAR DEFAUT.

Ne définissez pas la version ou ne démarrez pas de session de mise à jour si vous voulez mettre à jour des données dans la version de géodatabase PAR DEFAUT via une vue versionnée. Suivez la procédure ci-dessous :

1. Créez une vue versionnée d'une table ou d'une classe d'entités versionnée, s'il n'en existe pas.
   Remarque :

   Si la vue versionnée a été créée avant ArcGIS 10.1, vous devez la recréer ; les vues versionnées plus anciennes ne peuvent pas être mises à jour dans la version PAR DEFAUT.

2. Effectuez vos mises à jour sur la vue versionnée avec SQL. Vous modifierez automatiquement l'état courant de la version PAR DEFAUT.
3. Appliquez vos mises à jour à la base de données ou annulez-les. Il vaut mieux valider ou restaurer après chaque mise à jour parce que, pendant que votre transaction est ouverte, les verrouillages exclusifs sont maintenus sur les tables de deltas. Les verrous ne sont pas libérés tant que la transaction n'est pas terminée.