Suite

Modifier la vue de table de version par défaut à l'aide de SQL Server

Modifier la vue de table de version par défaut à l'aide de SQL Server


J'ai une configuration de géodatabase ArcSDE (10.3) qui est versionnée car nous avons quelques personnes travaillant simultanément sur les données. Cependant, je souhaite exécuter des scripts d'arrière-plan dans SQL Server pour mettre à jour la version par défaut lorsque personne ne travaille réellement sur les données.

Quoi qu'il en soit, les données que je vais éditer sont en fait une classe d'entités. Je ne fais aucun changement de géométrie, mais je change juste quelques valeurs d'attribut. Cependant, ce changement d'attribut est basé sur une jointure à une autre table SDE résidant dans la même base de données.

ESRI indique que les modifications apportées à partir de SQL Server doivent être apportées à la table VIEW plutôt qu'à la table de base réelle. Cependant, lorsque j'exécute mon script, cette erreur s'affiche :

Msg 414, niveau 16, état 1, ligne 6 UPDATE n'est pas autorisé car l'instruction met à jour la vue "dbo.MyTable_evw" qui participe à une jointure et a un déclencheur INSTEAD OF UPDATE.

Comment d'autres personnes ont-elles contourné ce problème ?

Exemple d'instruction de mise à jour qui renvoie l'erreur mentionnée ci-dessus.

BEGIN TRANSACTION EXEC set_default UPDATE [dbo].[MyFeatureClass_evw] SET [dbo].[MyFeatureClass_evw].[Status] = [dbo].[MySDEDataTable].[Status_2], FROM [dbo].[MyFeatureClass_evw] INNER JOIN [dbo] .[MySDEDataTable] ON [dbo].[MyFeatureClass_evw].[PrimaryKey] = [dbo].[MySDEDataTable].[PrimeKey] COMMIT;

La méthode de @MickyT fonctionne très bien. En outre, il convient de mentionner que j'ai également reçu la commande MERGE pour effectuer cette opération également.

MERGE MyFeatureClass_evw en tant que TargetTable EN UTILISANT MySDEDataTable en tant que SourceTable ON TargetTable.PrimaryKey = SourceTable.PrimeKey LORSQU'IL CORRESPOND ALORS METTRE À JOUR SET TargetTable.Status = SourceTable.Status_2 ;

Cela semble avoir été un problème avec SQL Server depuis un certain temps maintenant. Je ne sais pas pourquoi ils ne le permettent pas. Si vous modifiez votre déclaration de mise à jour en quelque chose comme ceci, cela devrait fonctionner.

UPDATE [dbo].[MyFeatureClass_evw] SET [dbo].[MyFeatureClass_evw].[Status] = ( SELECT A.[Status_2] FROM [dbo].[MySDEDataTable] AS A WHERE [dbo].[MyFeatureClass_evw].[PrimaryKey] = A.[PrimeKey] ), [dbo].[MyFeatureClass_evw].[Value] = ( SELECTIONNER A.[Value_2] FROM [dbo].[MySDEDataTable] COMME UN O [dbo].[MyFeatureClass_evw].[PrimaryKey] = A.[PrimeKey] ) WHERE EXISTS ( SELECT 1 FROM [dbo].[MySDEDataTable] AS A1 WHERE [dbo].[MyFeatureClass_evw].[PrimaryKey] = A1.[PrimeKey] )

Cela peut devenir un peu verbeux avec la répétition des requêtes SELECT pour chaque colonne mise à jour, mais cela fonctionne.


Comment stocker CHANGE_TRACKING_CURRENT_VERSION lors de l'utilisation du suivi des modifications SQL Server ?

J'utilise le suivi des modifications dans SQL Server (15) sur une seule table. Mon application cliente s'exécute tous les X minutes et vérifie si les données de la table ont été modifiées pour invalider certains caches. Au sein d'une seule transaction, le client obtient d'abord la version actuelle du suivi des modifications ( CHANGE_TRACKING_CURRENT_VERSION() ), puis recherche les modifications par rapport à la date d'exécution précédente du client. Le client sait quelle était la valeur précédente de CHANGE_TRACKING_CURRENT_VERSION() car il stocke sa valeur dans une table séparée (de la même base de données) après une exécution réussie. Ainsi, lorsque le client a terminé, le client écrase la version précédente du suivi des modifications par la version actuelle.

Pour éviter d'invalider le cache lorsque rien n'a été modifié, le client vérifie entre autres si la version de suivi des modifications est plus grande qu'avant. Cependant, étant donné que le client stocke la version précédente du suivi des modifications dans la base de données elle-même (ce qui entraîne l'incrémentation de la version), la version actuelle du suivi des modifications sera toujours plus grande que la version précédente stockée du suivi des modifications.

Par exemple, disons que la version stockée est 5 et la version actuelle est 6. Le client s'exécutera et finira par écraser la version stockée avec la version actuelle. Maintenant, la valeur stockée est 6, mais comme le stockage de cette valeur est considéré comme une modification par SQL Server Change Tracking, la version actuelle du suivi des modifications deviendra 7. Lors de la prochaine exécution, le client s'exécutera à nouveau (car 7 est supérieur à 6) et il finira par écraser à nouveau la version stockée avec la version actuelle. Ça va continuer comme ça pour toujours.

Existe-t-il un moyen de résoudre ce problème sans avoir à stocker la version précédente du suivi des modifications dans une base de données différente ?


Changer la version de la base de données SQL Server

J'ai une base de données de version SQL Server 2008 (numéro de version 655). Si j'essaye de créer pour l'attacher à un SQL Server 2005 ou SQL Server 2000, j'obtiens une erreur :

Cette base de données est la version 655. Ce serveur est compatible avec la version 612 ou antérieure

Bien sûr, je peux attacher la base de données à SQL Server 2008 sans erreur. Je sais que je peux générer des commandes SQL pour la structure, mais il y a aussi beaucoup de données dans de nombreuses tables.

Si je peux modifier la version de la base de données interne (le niveau de compatibilité est désormais défini sur SQL Server 2000), le processus d'attachement dans n'importe quelle version du serveur fonctionnera, car ce processus met automatiquement à jour la version.

EDIT : je viens de me rendre compte que si la mise à jour du numéro de version est automatique, il n'y aura aucun moyen de faire un changement de version. Alors, je reformule la question :

Connaissez-vous un outil qui génère un « package » avec des données et une structure compatible pour les versions SQL Server de 2000 à 2008 ? Un outil ou un script, peut-être.


Création de vue versionnée

Les vues versionnées sont automatiquement créées pour les tables ou les classes d'entités qui sont enregistrées comme versionnées dans ArcGIS 10.1 ou versions ultérieures. Si vous enregistrez un jeu de classes d'entités comme versionné, une vue versionnée est créée sur chaque classe d'entités du jeu de classes d'entités. La vue créée porte le même nom que la table ou la classe d'entités avec _evw ajouté à la fin.

Héritage:

Les vues créées avec ArcGIS 10.1 portent le même nom que la table ou la classe d'entités avec _vw ajouté à la fin.

Si les données ont été enregistrées comme versionnées dans ArcGIS 10 ou une version antérieure, vous pouvez créer une vue versionnée à partir d'ArcGIS for Desktop 10.1 ou d'une version ultérieure en cliquant avec le bouton droit sur la table, la classe d'entités ou le jeu de données d'entité, en pointant sur Gérer et en cliquant sur Activer l'accès SQL .


Création d'une table temporelle avec une table d'historique définie par l'utilisateur

La création d'une table temporelle avec une table d'historique définie par l'utilisateur est une option pratique lorsque l'utilisateur souhaite spécifier une table d'historique avec des options de stockage spécifiques et des index supplémentaires. Dans l'exemple ci-dessous, une table d'historique définie par l'utilisateur est créée avec un schéma aligné sur la table temporelle qui sera créée. Pour cette table d'historique définie par l'utilisateur, un index cluster columnstore et un index rowstore (B-tree) non clusterisé supplémentaire sont créés pour les recherches de points. Une fois cette table d'historique définie par l'utilisateur créée, la table temporelle versionnée par le système est créée en spécifiant la table d'historique définie par l'utilisateur comme table d'historique par défaut.

Remarques importantes

  • Si vous prévoyez d'exécuter des requêtes analytiques sur les données historiques qui utilisent des agrégats ou des fonctions de fenêtrage, la création d'un magasin de colonnes en cluster en tant qu'index principal est fortement recommandée pour la compression et les performances des requêtes.
  • Si le cas d'utilisation principal est l'audit de données (c'est-à-dire la recherche de modifications historiques pour une seule ligne de la table actuelle), alors un bon choix consiste à créer une table d'historique de magasin de lignes avec un index clusterisé
  • La table d'historique ne peut pas avoir de clé primaire, de clés étrangères, d'index uniques, de contraintes de table ou de déclencheurs. Il ne peut pas être configuré pour la capture de données modifiées, le suivi des modifications, la réplication transactionnelle ou de fusion.

La version de SQL Server Integration Services s'aligne sur la version de SQL Server que vous avez installée.

Pour déterminer la version de SQL Server Analysis Services, utilisez l'une des méthodes suivantes :

Méthode 1 : Connectez-vous au serveur à l'aide de l'Explorateur d'objets dans SQL Server Management Studio. Une fois l'Explorateur d'objets connecté, il affiche les informations de version entre parenthèses, ainsi que le nom d'utilisateur utilisé pour se connecter à l'instance spécifique d'Analysis Services.

Méthode 2 : Vérifiez la version du fichier Msmdsrv.exe dans le dossier bin Analysis Services. Les emplacements par défaut sont indiqués dans le tableau suivant.

Méthode 3: Utilisez les sous-clés de Registre répertoriées dans le tableau suivant.

Version des services d'analyse Lieu
2019 HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS15.InstanceNameMSSQLServerCurrentVersion Clé : CurrentVersion HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS15.InstanceName Setup Clés : PatchLevel , Version, Key Edition
2017 HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS14.InstanceNameMSSQLServerCurrentVersion Clé : CurrentVersion HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS14.InstanceName Setup Clés : PatchLevel , Version, Key Edition
2016 HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS13.InstanceNameMSSQLServerCurrentVersion Clé : CurrentVersion HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS13.InstanceName Setup Clés : PatchLevel , Version, Key Edition
2014 HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS12.InstanceNameMSSQLServerCurrentVersion Clé : CurrentVersion HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS12.InstanceName MSSQLServerCurrentVersion Clé : CurrentVersion
2012 HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS11.InstanceNameMSSQLServerCurrentVersion Clé : CurrentVersion HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSAS11.InstanceName Setup Clés : PatchLevel , Version, Key Edition

Pour plus d'informations sur la vérification des versions de build d'Analysis Services, consultez Vérifier la version de build de mise à jour cumulative d'Analysis Services.


Nettoyage de la table d'historique de SQL Server

Au fil du temps, la table d'historique peut s'allonger considérablement. Étant donné que l'insertion, la mise à jour ou la suppression de données de la table d'historique ne sont pas autorisées, le seul moyen de nettoyer la table d'historique est d'abord de désactiver la gestion des versions du système :

Supprimez les données inutiles de la table d'historique :

puis réactivez la gestion des versions du système :

Le nettoyage de la table d'historique dans Azure SQL Databases est un peu différent, car les bases de données Azure SQL ont une prise en charge intégrée pour le nettoyage de la table d'historique. Tout d'abord, le nettoyage de la rétention de l'historique temporel doit être activé au niveau de la base de données :

Définissez ensuite la période de rétention par table. :

Cela supprimera toutes les données de la table d'historique datant de plus de 90 jours.

Les bases de données sur site SQL Server 2016 ne prennent pas en charge TEMPORAL_HISTORY_RETENTION et HISTORY_RETENTION_PERIOD et l'une des deux requêtes ci-dessus est exécutée sur les bases de données sur site SQL Server 2016, les erreurs suivantes se produisent :

Pour TEMPORAL_HISTORY_RETENTION, l'erreur sera :

Msg 102, niveau 15, état 6, ligne 34
Syntaxe incorrecte près de ‘TEMPORAL_HISTORY_RETENTION’.

Pour HISTORY_RETENTION_PERIOD, l'erreur sera :

Msg 102, niveau 15, état 1, ligne 39
Syntaxe incorrecte près de ‘HISTORY_RETENTION_PERIOD’.

Marko alias "Zivko" est un analyste logiciel senior de Nis, en Serbie, qui se concentre sur SQL Server et MySQL ainsi que sur les technologies client telles que SSMS, Visual Studio et VSCode. Il possède une vaste expérience de l'assurance qualité, de l'escalade/résolution des problèmes et de l'évangélisation des produits.

Il est un auteur prolifique de contenu faisant autorité lié à SQL Server, y compris un certain nombre d'articles « platine » (top 1% en termes de popularité et d'engagement). Ses écrits couvrent une gamme de sujets sur MySQL et SQL Server, notamment les serveurs distants/liés, l'importation/exportation, LocalDB, SSMS, etc.

À temps partiel, Zivko aime le basket-ball, le baby-foot (football de table) et la musique rock.

Articles Similaires:


Avantages de l'utilisation de la capture de données modifiées ou du suivi des modifications

La possibilité d'interroger les données qui ont changé dans une base de données est une exigence importante pour que certaines applications soient efficaces. En règle générale, pour déterminer les modifications de données, les développeurs d'applications doivent implémenter une méthode de suivi personnalisée dans leurs applications en utilisant une combinaison de déclencheurs, de colonnes d'horodatage et de tables supplémentaires. La création de ces applications implique généralement beaucoup de travail à implémenter, conduit à des mises à jour de schéma et entraîne souvent une surcharge de performances élevée.

L'utilisation de la capture de données modifiées ou du suivi des modifications dans les applications pour suivre les modifications dans une base de données, au lieu de développer une solution personnalisée, présente les avantages suivants :

Le temps de développement est réduit. Étant donné que la fonctionnalité est disponible dans SQL Server 2019 (15.x), vous n'avez pas besoin de développer une solution personnalisée.

Les changements de schéma ne sont pas nécessaires. Vous n'avez pas besoin d'ajouter de colonnes, d'ajouter des déclencheurs ou de créer une table annexe dans laquelle suivre les lignes supprimées ou stocker les informations de suivi des modifications si les colonnes ne peuvent pas être ajoutées aux tables utilisateur.

Il y a un mécanisme de nettoyage intégré. Le nettoyage pour le suivi des modifications est effectué automatiquement en arrière-plan. Le nettoyage personnalisé des données stockées dans une table annexe n'est pas requis.

Des fonctions sont fournies pour obtenir des informations sur les modifications.

Il y a peu de temps système pour les opérations DML. Le suivi des modifications synchrones aura toujours une certaine surcharge. Cependant, l'utilisation du suivi des modifications peut aider à minimiser les frais généraux. Le surcoût sera souvent inférieur à celui de l'utilisation de solutions alternatives, en particulier des solutions qui nécessitent l'utilisation de déclencheurs.

Le suivi des modifications est basé sur les transactions validées. L'ordre des modifications est basé sur l'heure de validation de la transaction. Cela permet d'obtenir des résultats fiables lorsqu'il y a des transactions de longue durée et qui se chevauchent. Des solutions personnalisées qui utilisent horodatage les valeurs doivent être spécifiquement conçues pour gérer ces scénarios.

Des outils standard sont disponibles que vous pouvez utiliser pour configurer et gérer. SQL Server 2019 (15.x) fournit des instructions DDL standard, SQL Server Management Studio, des vues de catalogue et des autorisations de sécurité.


Arguments

nom de la propriété
Est une expression qui contient les informations de propriété à renvoyer pour le serveur. nom de la propriété peut être l'une des valeurs suivantes.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

NULL = L'entrée n'est pas valide ou une erreur.

Pour une instance en cluster de SQL Server sur un cluster de basculement, cette valeur change lorsque l'instance de SQL Server bascule vers d'autres nœuds du cluster de basculement.

Sur une instance autonome de SQL Server, cette valeur reste constante et renvoie la même valeur que la propriété MachineName.

Noter: Si l'instance de SQL Server se trouve dans un cluster de basculement et que vous souhaitez obtenir le nom de l'instance en cluster de basculement, utilisez la propriété MachineName.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

'Enterprise Edition : Licences basées sur le cœur'

« Édition d'évaluation d'entreprise »

'Édition Business Intelligence'

'Édition Express avec Services Avancés'

« SQL Azure » ​​indique la base de données SQL ou Microsoft Azure Synapse Analytics

« Azure SQL Edge Developer » indique l'édition de développement uniquement pour Azure SQL Edge

« Azure SQL Edge » indique l'édition payante pour Azure SQL Edge

1872460670 = Enterprise Edition : Licences basées sur le cœur

610778273= Évaluation d'entreprise

284895786 = Intelligence d'affaires

-133711905= Express avec services avancés

1674378470 = Base de données SQL ou Azure Synapse Analytics

-1461570097 = Développeur Azure SQL Edge

1994083197 = Azure SQL Edge

1 = Moteur personnel ou de bureau (non disponible dans SQL Server 2005 (9.x) et versions ultérieures.)

2 = Standard (Ceci est renvoyé pour Standard, Web et Business Intelligence.)

3 = Enterprise (Ceci est renvoyé pour les éditions Evaluation, Developer et Enterprise.)

4 = Express (Ceci est renvoyé pour Express, Express avec outils et Express avec services avancés)

6 = Microsoft Azure Synapse Analytics

8 = Instance gérée Azure SQL

9 = Azure SQL Edge (Ceci est renvoyé pour toutes les éditions d'Azure SQL Edge)

11 = pool SQL sans serveur Azure Synapse

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Indique si le gestionnaire de groupes de disponibilité Always On a démarré.

0 = Non démarré, communication en attente.

2 = Non démarré et a échoué.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Nom du chemin d'accès par défaut aux fichiers de données d'instance.

Nom du chemin d'accès par défaut aux fichiers journaux d'instance.

Renvoie NULL si le nom de l'instance est l'instance par défaut, si l'entrée n'est pas valide, ou erreur.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Renvoie 1 si l'instance est SQL Server Big Data Cluster 0 sinon.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

1 = L'authentification Azure AD uniquement est activée.

0 = L'authentification Azure AD uniquement est désactivée.

1 = Les composants d'indexation de texte intégral et sémantique sont installés.

0 = Les composants d'indexation de texte intégral et sémantique ne sont pas installés.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Les groupes de disponibilité Always On sont activés sur cette instance de serveur.

0 = La fonctionnalité Groupes de disponibilité Always On est désactivée.

1 = La fonctionnalité Groupes de disponibilité Always On est activée.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Type de données de base : entier

Pour que les réplicas de disponibilité soient créés et exécutés sur une instance de SQL Server, les groupes de disponibilité Always On doivent être activés sur l'instance de serveur. Pour plus d'informations, consultez Activer et désactiver les groupes de disponibilité AlwaysOn (SQL Server).

1 = Sécurité intégrée (Authentification Windows)

0 = Sécurité non intégrée. (Authentification Windows et authentification SQL Server.)

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Le serveur est une instance de SQL Server Express LocalDB.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Renvoie si la fonction PolyBase est installée sur l'instance de serveur.

0 = PolyBase n'est pas installé.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Renvoie 1 si tempdb a été activé pour utiliser des tables à mémoire optimisée pour les métadonnées 0 si tempdb utilise des tables régulières sur disque pour les métadonnées. Pour plus d'informations, consultez Base de données tempdb.

Le serveur prend en charge l'OLTP en mémoire.

1= Le serveur prend en charge l'OLTP en mémoire.

0= Le serveur ne prend pas en charge l'OLTP en mémoire.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Pour une instance en cluster, une instance de SQL Server s'exécutant sur un serveur virtuel sur Microsoft Cluster Service, elle renvoie le nom du serveur virtuel.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

NULL = L'entrée n'est pas valide, une erreur ou n'est pas applicable.

Type de build de la build actuelle.

Renvoie l'un des éléments suivants :

OD = On Demand libère un client spécifique.

GDR = General Distribution Release publiée via la mise à jour de Windows.

Renvoie l'un des éléments suivants :

'RTM' = version originale

'SPm' = version du Service Pack

'CTPm', = version d'aperçu de la technologie communautaire

Niveau de mise à jour de la version actuelle. CU indique une mise à jour cumulative.

Renvoie l'un des éléments suivants :

Article de la base de connaissances pour cette version.

NULL = L'entrée n'est pas valide ou une erreur.


5 réponses 5

Le processus général

Nous créons une référence pour une version particulière (disons, v1.0 ). Une ligne de base comprend un script de création de schéma complet, ainsi qu'un script de mise à niveau à partir des versions précédentes autorisées, le cas échéant (plus de détails dans un instant). Donc pour la v1.0 , nous n'aurions qu'un seul script :

À partir de cette ligne de base, nous créons des scripts de changement incrémentiel tout en travaillant à partir de la ligne de base précédente. Ces scripts sont créés de manière à être réentrants, de sorte qu'ils puissent être exécutés plusieurs fois en toute sécurité (là où la première fois ne fait qu'un travail réel, voir le paragraphe suivant sur une suggestion comment). Nous créons simplement un fichier pour chaque script de modification avec le nom de la ligne de base et un horodatage (que nous appelons la version). Par exemple, disons que nous créons deux scripts de modification après une ligne de base. Nous aurions les fichiers suivants :

Nous créons une table schema_version qui a deux colonnes : baseline et version . la ligne de base est une étiquette (comme la v1.0 mentionnée ci-dessus), et la version n'est qu'un horodatage du moment où le script de modification a été créé (nous avons choisi de le faire car la création de numéros de version arbitraires créait une surcharge administrative ennuyeuse, où un horodatage était facile à utiliser ). Ainsi, avant d'exécuter le script de modification, nous vérifions si le script de modification a déjà été appliqué, en l'interrogeant par ligne de base et version . S'il est déjà présent, revenez simplement hors du script ou autre. Sinon, appliquez la modification et insérez-la dans la table schema_version pour marquer le script de modification terminé.

Maintenant, lorsque nous installons réellement le logiciel, nous exécutons le script de base approprié. Au fur et à mesure que nous mettons à niveau cette version, nous appliquons simplement les scripts de modification dans l'ordre.

Lorsque nous franchissons une étape importante dans notre phase de développement de produits, nous créons une nouvelle base de référence. Nous créons donc un nouveau script de référence (encore une fois, il s'agit d'un instantané de la base de données en tant que référence), ainsi qu'un script de mise à niveau à partir de la référence précédente. Supposons donc que nous ayons une nouvelle référence, v2.0 , nous aurions les fichiers suivants :

Ensuite, le processus continue.

Comment nous appliquons les changements

Les scripts sont tous conservés dans le contrôle de source. Nous disposons d'un outil qui regroupe ces fichiers et met automatiquement à niveau les bases de données, que nos équipes de support et d'installation utilisent. L'outil détermine la ligne de base actuelle de la base de données cible et demande à l'utilisateur s'il souhaite passer à la ligne de base dans le package. Si tel est le cas et qu'il existe un chemin de mise à niveau valide à partir de la version actuelle, il applique le script de mise à niveau et met à jour le fichier schema_version.baseline , et supprime toutes les entrées pour les scripts de modification de la ligne de base précédente. Si la base de données est nouvelle, elle applique le script de base standard. Dans tous les cas, une fois la ligne de base atteinte, il applique tous les scripts de modification de la ligne de base présents dans le package, un par un, dans l'ordre, dans une transaction. Si un script de modification particulier échoue, il annule le dernier ensemble de modifications et d'erreurs. Nous examinons le journal, résolvons les problèmes, puis réexécutons à nouveau le package. À ce stade, il devrait simplement reprendre le dernier script de modification qui a réussi, ce qui vous fait gagner du temps.

Outils d'automatisation et de différenciation

Nous n'autorisons pas les outils de comparaison à mettre à niveau directement les bases de données de production. C'est juste trop risqué. Nous utilisons des outils de comparaison, bien sûr, pour aider à créer nos scripts de mise à niveau et de modification, mais une fois que nous les avons, nous les passons en revue, les massons, les testons, etc., puis créons le script de mise à niveau ou de modification selon les spécifications ci-dessus. . Nous utilisons des outils/des scripts shell pour créer les fichiers de script de modification et mettre la vérification schema_version de la plaque chauffante.

C'est en fait assez simple et ça marche bien. La seule fois où cela devient vraiment délicat, c'est avec les branches. Pour la plupart, les branches sont bien gérées. Si nous avons besoin d'un script de modification pour le travail d'une branche particulière, il s'intégrera très bien dans la ligne principale une fois que nous fusionnerons la branche. Pas de problème. Là où cela devient difficile, c'est lorsque deux branches essaient de faire des choses similaires, ou lorsqu'une branche s'appuie sur une autre. C'est surtout un problème de processus et de planification, cependant. Si nous restons bloqués dans une telle situation, nous créons simplement une nouvelle ligne de base (disons v2.1 ), puis mettons à jour les branches en conséquence.

Une autre chose à garder à l'esprit est que si une installation veut être mise à niveau d'une ligne de base à une autre, elle doit appliquer toutes les modifications en suspens pour la ligne de base actuelle, avant de passer à la nouvelle. En d'autres termes, nous ne laissons pas les installations sauter directement de l'endroit où elles se trouvent à la référence suivante (à moins, bien sûr, qu'elles soient déjà à la version la plus récente pour la référence actuelle).


Tables système d'une géodatabase dans SQL Server

Les tables système d'une géodatabase appliquent le comportement de la géodatabase, stockent des informations sur la géodatabase et assurent le suivi des données stockées dans la géodatabase.

Pour voir un diagramme des tables système de la géodatabase, cliquez ici . (Vous aurez besoin d'Adobe Reader pour ouvrir ce fichier.)

Ce qui suit est une liste alphabétique et une description des tables système pour une géodatabase stockée dans un SGBD SQL Server. Vous pouvez utiliser les liens ci-dessous pour accéder aux sections de la liste.

REMARQUE : les tables système ne doivent pas être modifiées à l'aide d'autre chose que le logiciel ArcGIS.

La table GCDRULES stocke les règles de géocodage utilisées par les localisateurs d'adresses pour faire correspondre les adresses. Chaque enregistrement de la table GCDRULES correspond à un fichier de règles de géocodage.

cls = Tableau de classement

dct = dictionnaire de clés de correspondance

stn = processus de normalisation

tapis = spécification correspondante

tbl = Tables supplémentaires (facultatif)

La table GDB_ANNOSYMBOLS contient une annotation de classe d'entités .

La table GDB_ATTRRULES contient les règles attributaires dans la géodatabase.

La table GDB_CODEDDOMAINS contient des valeurs pour chaque domaine de valeur codée.

La table GDB_DEFAULTVALUES contient les valeurs par défaut des champs au niveau du sous-type ou de la classe d'objets.

La table GDB_DOMAINS contient les contraintes d'attribut associées aux règles d'attribut de la table GDB_ATTRRULES.

1 = somme des valeurs—L'attribut de l'entité résultant d'une fusion sera la somme des valeurs des deux entités d'origine (préfusion).

2 = géométrie pondérée—L'attribut de l'entité qui résulte d'une fusion est la moyenne pondérée des valeurs des attributs des entités d'origine (préfusion). La moyenne est basée sur la géométrie des entités d'origine.

1 = rapport géométrique—Les attributs des entités résultant de la division sont un rapport de la valeur (pré-spliée) de l'entité d'origine. Le rapport est basé sur le rapport dans lequel la géométrie est divisée par la division.

2 = dupliquer—L'attribut des caractéristiques résultant de la division est le même que la valeur de l'attribut (pré-divisé) de l'objet d'origine.

La table GDB_EDGECONNRULES contient un enregistrement par règle de connectivité de tronçon dans un réseau géométrique.

Nom de domaine Type de champ La description
ID de règle entier L'ID unique d'une règle dans la géodatabase et la clé étrangère du champ ID dans la table GDB_VALIDRULES
FromClassID entier L'ID de classe d'objet de la classe d'entités from et la clé étrangère de l'ID dans la table GDB_GEOMNETWORKS
DeSous-type entier Le sous-type de la classe d'entités de bord
VersIDClasse entier L'ID de classe d'objet de la classe d'entités à et la clé étrangère de l'ID dans la table GDB_GEOMNETWORKS
Sous-type entier Le sous-type de la classe d'entités jusqu'au bord
Jonctions image Contient des informations relatives à la classe d'entités jonction

GDB_EXTENSIONDATASETS

La table GDB_EXTENSIONDATASETS contient des informations sur les extensions de jeu de données (telles que les jeux de données réseau ou les jeux de données de MNT) dans une géodatabase.

La table GDB_EXTENSIONS stocke les extensions enregistrées avec cette géodatabase.

La table GDB_FEATURECLASSES contient des informations sur toutes les classes d'entités de la géodatabase.

1 = point, multipoint, ligne, polygone ou multipatch

4 = polygone (y compris annotation et dimension)

La table GDB_FEATUREDATASET suit les informations sur les classes d'entités regroupées en jeux de données dans la géodatabase. Ceux-ci incluent des jeux de données d'entités, des jeux de données raster, des jeux de données réplicas, des jeux de données de MNT, des jeux de données de topographie et des jeux de données réseau.

La table GDB_FIELDINFO contient le nom de champ, les valeurs de noms de domaine par défaut et les valeurs de chaîne et de nombre par défaut pour des champs d'attribut spécifiques associés à une classe d'objets.

La table GDB_GEOMNETWORKS contient un enregistrement par réseau géométrique dans la géodatabase. Si aucun réseau logique autonome ou jeu de données réseau n'existe dans la géodatabase, il y aura un mappage un à un des tables GDB_GEOMNETWORKS et GDB_NETWORKS.

GDB_HISTORICALMARKERS

La table GDB_HISTORICALMARKERS contient une liste de marqueurs utilisés pour la navigation des moments dans une version historique.

Nom de domaine Type de champ La description
HM_NAME varchar(64) Le nom du marqueur historique
HM_TIMESTAMP dateheure Le moment où le marqueur historique fait référence

Le GDB_JNCONNRULES contient un enregistrement par règle de connectivité de jonction dans un réseau géométrique.

La table GDB_NETCLASSES contient un enregistrement par classe d'entités qui participe à un réseau géométrique dans une géodatabase.

La table GDB_NETWEIGHTASOCS contient un enregistrement par association entre les classes de réseau et les poids de réseau des réseaux géométriques.

Nom de domaine Type de champ La description
ID de réseau entier L'ID unique d'un réseau géométrique dans une géodatabase et une clé étrangère du champ ID dans la table GDB_GEOMNETWORKS
ID de poids entier L'identifiant unique d'un poids dans un réseau géométrique et la clé étrangère du champ ClassID dans la table GDB_NETCLASSES
Nom de la table varchar(160) Le nom de la table contenant le champ auquel le poids du réseau a été associé
Nom de domaine varchar(32) Le nom du champ auquel le poids a été associé

La table GDB_NETWEIGHTS contient un enregistrement par pondération pour les réseaux dans une géodatabase.

(Les poids NonBitGate ont une valeur de 0.)

La table GDB_NETWORKS contient un enregistrement par réseau logique dans la géodatabase.

Le GDB_OBJECTCLASSES contient toutes les classes d'objets de la géodatabase. Les classes d'objets de la géodatabase incluent les classes d'entités, les classes de relations, les catalogues d'images, les topologies et les tables autonomes.

La table GDB_RANGEDOMAINS contient la plage de valeurs pour chaque domaine de plage.

Nom de domaine Type de champ La description
ID de domaine entier Clé étrangère du champ ID dans la table GDB_DOMAINS
MinValue numérique La valeur la plus basse autorisée dans la plage
Valeur max numérique La plus grande valeur admissible dans la gamme

La table GDB_RASTERCATALOGS stocke une référence à chaque catalogue d'images dans la géodatabase.

Nom de domaine Type de champ La description
IDClasseObjet entier Clé étrangère du champ ID dans la table GDB_OBJECTCLASSES
RasterChamp varchar(32) Nom du champ raster
IsRasterDataset entier 0 (pas un jeu de données raster) ou 1 (un jeu de données raster)

La table GDB_RELCLASSES contient les relations de table dans la géodatabase. Toutes les métadonnées système requises pour gérer les relations, telles que la cardinalité et les identifiants des classes d'origine et de destination, sont stockées dans la table GDB_RELCLASSES.

1 = aucun (aucun message propagé).

2 = renvoi (origine vers destination).

La table GDB_RELEASE stocke les informations de version de la géodatabase sous la forme d'un enregistrement unique. Cet enregistrement unique reflète la version actuelle installée.

La table GDB_RELRULES contient les règles de relation de classe d'objets.

La table GDB_REPLICADATASETS contient des informations relatives à chaque ensemble de données extrait ou répliqué.

Chaque fois qu'une réplique exporte ou importe des modifications, les informations sur l'opération sont stockées dans la table GDB_REPLICALOG.

Nom de domaine Type de champ La description
identifiant entier Identifiant unique pour la ligne.
ID de réplica entier Clé étrangère du champ ID dans la table GDB_REPLICAS.
Événement entier Indique si une importation (1) ou une exportation (2) a été enregistrée.
Code d'erreur entier Le code d'erreur associé à l'événement, vous pouvez rechercher l'aide du développeur pour obtenir la description associée à l'erreur. Si l'événement a réussi, un code d'erreur de réussite est renvoyé.
LogDate dateheure La date à laquelle l'événement s'est produit.
SourceBeginGen entier Plusieurs générations de modifications de données peuvent être importées ou exportées en un seul événement. Cette valeur indique le numéro de génération de la première génération de changements impliqués. Par exemple, si les générations 1 à 3 étaient importées, ce champ aurait la valeur 1.
SourceFinGen entier Plusieurs générations de modifications de données peuvent être importées ou exportées en un seul événement. Cette valeur indique le numéro de génération de la dernière génération de changements impliqués. Par exemple, si les générations 1 à 3 étaient importées, ce champ aurait la valeur 3.
Génération cible entier La génération à laquelle les modifications doivent être appliquées, cette valeur est utilisée pour appliquer les modifications à la version appropriée dans le réplica cible.

La table GDB_REPLICAS contient les métadonnées de chaque réplica de la géodatabase.

La table GDB_REPLICASEX contient des informations supplémentaires sur chaque réplique stockée dans la table GDB_REPLICAS. Il dispose également d'un enregistrement de métadonnées pour chaque réplique.

La table GDB_SPATIALRULES n'est pas utilisée pour le moment.

La table GDB_SUBTYPES contient les sous-types valides des classes d'objets de géodatabase.

GDB_TABLES_LAST_MODIFIED

The GDB_TABLES_LAST_MODIFIED table is used to validate geodatabase system tables when cached by the client application.

Field name Field type La description
table_name varchar(160) Name of the geodatabase system table
last_modified_count entier Keeps a count of the number of times a system table is modified incrementally increases each time the system table is modified

The GDB_TOOLBOXES table contains one record of metadata for each toolbox stored in the geodatabase.

The GDB_TOPOCLASSES table contains one record per feature class that participates in a topology.

The GDB_TOPOLOGIES table contains one record per topology in the geodatabase.

The GDB_TOPORULES table contains one record per rule in each topology.

The GDB_USERMETADATA table stores user-defined metadata for all parts of the geodatabase including object classes, feature classes, feature datasets, logical networks, and relationship classes.

The GDB_VALIDRULES table contains all the valid rules of the geodatabase. This includes the attribute rules, edge connectivity rules, junction connectivity rules, relationship rules, topology rules, geocoding rules, and spatial rules.

The SDE_archives table stores the metadata for the archives in a geodatabase.

Field name Field type La description
archiving_regid entier The table's registration ID
history_regid entier The archive table's registration ID
from_date nvarchar(32) The name of the from date field
to_date nvarchar(32) The name of the to date field
archive_date bigint The creation date of the archive
archive_flags bigint Not currently used

The SDE_column_registry table manages all registered columns.

NOTE: If you alter column definitions using a SQL interface, the records in the SDE_column_registry table are not updated. This may cause any subsequent exports of the data to fail.

1 = SE_INT16_TYPE𔃊-byte Integer

2 = SE_INT32_TYPE 𔃌-byte Integer

3 = SE_FLOAT32_TYPE𔃌-byte Float

4 = SE_FLOAT64_TYPE𔃐-byte Float

5 = SE_STRING_TYPE—Null Term Character Array

6 = SE_BLOB_TYPE—Variable Length Data

7 = SE_DATE_TYPE—Struct tm Date

8 = SE_SHAPE_TYPE—Shape geometry (SE_SHAPE)

10 = SE_XML_TYPE—XML Document

11 = SE_INT64_TYPE𔃐-byte Integer

12 = SE_UUID_TYPE—A Universal Unique ID

13 = SE_CLOB_TYPE—Character variable length data

14 = SE_NSTRING_TYPE—UNICODE Null Term Character Array

15 = SE_NCLOB_TYPE—UNICODE Character Large Object

20 = SE_POINT_TYPE—Point UDT

21 = SE_CURVE_TYPE—LineString UDT

22 = SE_LINESTRING_TYPE—LineString UDT

23 = SE_SURFACE_TYPE—Polygon UDT

24 = SE_POLYGON_TYPE— Polygon UDT

25 = SE_GEOMETRYCOLLECTION_TYPE 25 /* MultiPoint UDT */

26 = SE_MULTISURFACE_TYPE—LineString UDT

27 = SE_MULTICURVE_TYPE—LineString UDT

28 = SE_MULTIPOINT_TYPE—MultiPoint UDT

29 = SE_MULTILINESTRING_TYPE—MultiLineString UDT

30 = SE_MULTIPOLYGON_TYPE—MultiPolygon UDT

The SDE_compress_log table tracks all compress operations performed on the geodatabase.

NOTE: This table is not present if the geodatabase has never been compressed.

Field name Field type La description
compress_id entier Unique ID of a compress operation
sde_id entier Process identification number of the compress operation references sde_id column in SDE_process_information table
server_id entier System process_id of the ArcSDE server process that performed or is performing the compress operation
direct_connect varchar(1) Y (yes) or N (no) if the client is making a direct connection to the geodatabase
compress_start dateheure The date and time the compress operation was begun
start_state_count entier The number of states present when compress began
compress_end dateheure The date and time the compress operation completed
end_state_count entier The number of remaining states after the compress operation
compress_status varchar(20) Indicates whether or not the compress operation was successfully completed

The SDE_dbtune table stores the configuration keywords, parameters, and parameter values for datasets, such as feature classes. These define how the datasets are stored in the geodatabase.

The SDE_geometry_columns table stores a row for each column of type geometry in the database that complies with the OpenGIS SQL specification. ArcSDE treats this table as write only—the only time it is accessed by ArcSDE is when a layer is added or deleted that uses an OpenGIS SQL data format. This table is defined by the OpenGIS SQL specification and may be updated by other applications with geometry columns not managed by ArcSDE. When a new Geometry column is created in an OpenGIS compliant format, the fully qualified table, column name, and spatial reference ID (SRID) are added to the SDE_geometry_columns table.

Each geometry column is associated with a spatial reference system. Information on each spatial reference system is stored in the SDE_spatial_references table.

The SDE_layer_locks table maintains the locks on feature classes.

0 = A read lock on the entire layer

1 = A write lock on the entire layer

2 = A read lock on an area within the layer

3 = A write lock on an area within the layer

The SDE_layers table maintains data about each feature class in the database. The information helps build and maintain spatial indexes, ensure proper shape types, maintain data integrity, and store the spatial reference for the coordinate data.

This table stores a row for each spatial column in the database. Applications use the layer properties to discover available spatial data sources. The layer properties are used by ArcSDE to constrain and validate the contents of the spatial column, to index geometry values, and to properly create and manage the associated DBMS tables.

    Layer stores single precision or double precision coordinates.

SDE_lineages_modified

The SDE_lineages_modified table contains a state lineage identifier and its most recent modification time stamp.

Field name Field type La description
lineage_name bigint Foreign key to the lineage_name field in the SDE_state_lineages table
time_last_modified dateheure The date and time the lineage was last modified

The SDE_locators table stores information about locator objects. When you add a locator to a geodatabase stored in a DBMS, a row is added to the SDE_locators table. Each row in the SDE_locators table defines a locator or locator style.

The SDE_logfile_pool table will be present in the geodatabase when it is first created, regardless of what type of log files you use. For a description of this and other log file tables, see Log file tables in a geodatabase in SQL Server.

When you add a locator to a geodatabase in a DBMS, a row is added to the SDE_metadata table for each property of the locator. Each row in the SDE_metadata table defines a single property for a locator.

SDE_mvtables_modified

The SDE_mvtables_modified table maintains the list of all tables that are modified in each state of the database. This information aids in quickly determining if conflicts exist between versions or states of the database.

The SDE_mvtables_modified table maintains a record of all tables modified by state. This information allows applications to determine which tables need to be checked for changes when reconciling potential conflicts between versions and states in the database.

Any time a feature class or table is modified in a state, a new entry is created in the SDE_mvtables_modified table. When two versions are reconciled, the first step in the process is to identify the states these two versions reference—the current edit version’s state and the target version’s state. From these states, a common ancestor state is identified by tracing back through the state lineage of these two versions.

Field name Field type La description
state_id bigint The ID of the state in which this table was modified foreign key to the state_id field in the SDE_states table
registration_id entier The registration ID of the table that was modified in the state foreign key to the SDE_table_registry table

The SDE_object_locks table maintains locks on geodatabase objects.

SDE_process_information

The SDE_process_information table collects ArcSDE session statistics such as the number of records read and the number of records written while the session was active.

The SDE_raster_columns table contains a list of raster columns stored in the database.

This table references the raster data in the band, block, and auxiliary tables.

The SDE_server_config table stores ArcSDE server configuration parameters. These parameters define how the ArcSDE software uses uses memory.

Field name Field type La description
prop_name nvarchar(32) The initialization parameter name
char_prop_value nvarchar(512) The character value of the initialization parameter
num_prop_value entier The integer value of the initialization parameter

SDE_spatial references

The SDE_spatial_references table contains the coordinate system and floating point-to-integer transformation values. Internal functions use the parameters of a spatial reference system to translate and scale each floating point coordinate of the geometry into 64-bit positive integers prior to storage. Upon retrieval, the coordinates are restored to their original external floating point format.

Each geometry column of the SDE_geometry_columns table is associated with a spatial reference system, the information for which is stored in the SDE_spatial_references table. The columns of this table are those defined by the OpenGIS SQL Specification (SRID, SRTEXT, AUTH_NAME, and AUTH_SRID) and those required by ArcSDE for internal coordinate transformation. The spatial reference system identifies the coordinate system for a geometry and gives meaning to the numeric coordinate values for the geometry.

The SDE_state_lineages table stores the lineage of each state. A new lineage name is created for each version. Each time a state is added, the lineage name and the state ID are added. When a state is added that is a new version, the ancestry state lineage of the parent state is added with the lineage name.

To return the correct view of a version, its state lineage is queried to identify all the states that recorded each change made to that version. From this list of states, the table rows that correctly represent the version can be determined.

Field name Field type La description
lineage_name bigint Name that describes a state
lineage_id bigint Unique ID of individual states

The SDE_state_locks table maintains the version state locks.

0 = A shared lock on the entire state tree

1 = An exclusive lock on the entire state tree

2 = A shared lock on a state

3 = An exclusive lock on a state

The SDE_states table contains the state metadata. It accounts for the states that have been created over time, and the creation time, closing time, parent, and owner of each state.

When a state is created, a state ID is assigned and a record is added to this table.

The SDE_table_locks table maintains the locks on ArcSDE registered tables.

The SDE_table_registry table manages all registered tables. The values include an ID, table name, owner, and description.

    The table has a registered row ID.

The SDE_tables_modified table records when changes are made to the system tables. This information is used to eliminate unnecessary reads of tables that have not changed.

Field name Field type La description
table_name sysname Name of the ArcSDE system table that was modified
time_last_modified dateheure Date and time the table was modified

The SDE_version table maintains information about the version of ArcSDE with which the database expects to operate. The table contains the specific release identification for the most recently installed version of ArcSDE.

The SDE_version table and other ArcSDE system tables are updated after a new version of ArcSDE is installed.

Field name Field type La description
Majeur entier Number of the major release for example, for ArcSDE 9.1, the major release number would be 9.
mineur entier Number indicating the version of the major release for example, for ArcSDE 9.1, the minor release number would be 1.
bugfix entier Number of the patch or service pack installed.
la description nvarchar(96) Description of the ArcSDE installation.
Libération entier Complete release number for example, 92009.
sdesvr_rel_low entier Indicates the lowest release number of server allowed to run on this instance.

The SDE_versions table contains information about versioned geodatabases.

Each version is identified by a name, with an owner, description, and associated database state. This table defines the different versions that the database contains and provides a list of available versions to be presented to the user. These versions are used to access specific database states by the application. The version name and ID are unique.

When the VERSIONS table is first created by ArcSDE, a default version will be inserted into the table. This default version will be named DEFAULT, will be owned by the ArcSDE administrator, and granted PUBLIC access. The initial state_id will be set to 0, and the description string will read Instance Default Version. Since the default version has been granted PUBLIC access, any user can change the state of the default.

ArcGIS requires the presence of the default version. If you should inadvertently delete the default version, you can replace it with the following SQL insert statement.