MapInfo Native TAB

Native TAB est le format TAB le plus courant. Native extended TAB (NativeX) est identique à native TAB, sauf qu'il prend en charge les très gros fichiers (> 2 Go) et différentes langues. Les deux formats de native TAB présentent le même comportement.

Spectrum Spatial traite native TAB comme une source de données en lecture-écriture. Cependant, les opérations Insert, Update et Delete sont applicables uniquement pour les systèmes d’exploitation Windows et pour les systèmes hors cluster.

Types de données

Spectrum Spatial prend en charge les types de géométrie des fichiers TAB natifs : Point, MultiPoint, Linestring, MultiLineString, Polygon, MultiPolygon et MultiFeatureGeometry. Voici les correspondances des types de données TAB vers leurs équivalents Spectrum Spatial.

Type de données TAB	Type de données Spatial Spectrum
OBJ	Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, GeometryCollection. Objets rectangle, rounded rectangle (rectangle arrondi), ellipse, arc et text pris en charge comme constructions d'affichage uniquement.
integer	Entier
smallint	Court
flottant	Double
décimal	Double
char	Chaîne
largeint	Long
integer64	Long
date	Date
time	Durée
datetime	Date_Time
logical	Booléen

Clé principale

Native TAB comporte une clé primaire implicite qui correspond à l'ID de ligne. Cette colonne n’apparaît pas dans les données, comme ROWNUM dans Oracle.

Prise en charge de Insert, Update, et Delete

Les opérations Insert, Update et Delete sont prises en charge sur un fournisseur de source de données TAB avec les limites suivantes :

Un paramètre est disponible dans Spatial Manager lors de la création et de la modification de tables nommées pour permettre l’activation ou la désactivation de l’attribut en lecture seule pour la qualification des fichiers TAB (native et NativeX sous Windows) sur lesquels un utilisateur dispose des autorisations appropriées. Cependant, cela ne tient pas compte du fait que les métadonnées des fichiers TAB puissent comporter un indicateur de lecture seule ou qu'elles soient en lecture seule sur le système de fichiers.
Ces opérations sont prises en charge uniquement sur une seule instance d’une installation Spectrum™ Technology Platform. Elles ne sont pas non plus prises en charge sur un environnement en cluster, car il existerait un grand nombre de copies du fichier (sur chaque nœud, ce qui produirait des fichiers incohérents) ou un partage de fichiers est utilisé. Pour garantir les performances et l'évolutivité d'un environnement en cluster, les sources de base de données basées sur RDBMS telles que SQL Server, PostGIS ou Oracle doivent être utilisées pour l'écriture. Les fichiers Native et NativeX TAB ne sont pas conçus pour être utilisés de la même manière que des bases de données.
Ces opérations sont prises en charge uniquement quand le fichier TAB est local à l'instance Spectrum™ Technology Platform. Elles ne sont pas prises en charge si le fichier TAB se trouve sur un partage réseau. Cela est dû aux performances et au manque de fiabilité de l'accès en écriture en cas de partages de fichiers pour des fichiers TAB.
La lecture d'un fichier TAB à l'aide du stage Read Spatial Data ou Query Spatial Data et la réalisation d'une mise à jour ou d'une suppression sur le même fichier TAB via le stage Write Spatial Data dans le même flux ne sont pas recommandées, car, dans certains cas, cela crée une situation de blocage (dans laquelle l'opération de lecture bloque le fichier, empêchant l'opération d'écriture). Cela fonctionne uniquement si l’intervalle de validation est supérieur au nombre d’enregistrements en lecture depuis le même fichier TAB. En outre, en cas d'opération Insert, Update ou Delete à long terme dans un dataflow et d'opérations de lecture d'un service pour le même fichier TAB (par exemple, depuis les services Mapping, Feature ou Map Tiling), certaines requêtes de lecture risquent d'échouer, car le fichier TAB pourrait être verrouillé.
Lors de l'utilisation de Feature Service pour réaliser des opérations d'écriture sur des fichiers native TAB, toutes les requêtes de lecture pour ce fichier attendent que l'opération d'écriture soit terminée. Il est possible d'exécuter simultanément plusieurs opérations de lecture pour le même fichier TAB et une requête d'écriture attendra que toutes les requêtes de lecture soient terminées pour un fichier TAB.
Il n'est pas possible d'effectuer plusieurs processus d'accès en écriture pour un fichier TAB (par exemple, l’écriture dans un fichier TAB ne peut pas se produire si un autre outil tel que MapInfo Pro effectue également une tentative de lecture du fichier). L’opération d’écriture entraîne des échecs et le fichier TAB devient incohérent ou corrompu.

Optimisations de MI SQL

Le fournisseur de source de données native TAB contient des optimisations pour les constructions MI SQL suivantes :

EnvelopesIntersect
IN List
Opérateurs d'attribut (=, < >, < , <=, >, >=)

Pour plus d'informations, reportez-vous à l'annexe Délégation aux fournisseurs de données.

Volatilité de la source de données

Pour une source de données native TAB, la volatilité correspond à toute modification apportée au schéma ou aux enregistrements de la table, mise en évidence par une modification de l'horodatage. Lorsque la volatilité est activée (true), le fournisseur de source de données met en cache les informations sur un groupe de fichiers TAB spécifique. Il compare les horodatages des informations mises en cache à l’horodatage des fichiers en cours d’accès. S’ils sont différents, les informations sont supprimées du cache et rechargées.

La volatilité des fichiers native TAB suivants est vérifiée : .TAB, .DAT, .MAP.

Les opérations Insert, Update et Delete sont autorisées sur les fichiers native TAB volatils et non volatils. Lorsque vous rendez un fichier TAB accessible en écriture, il est recommandé d’activer également la volatilité.

Pour plus d'informations, reportez-vous à la section Volatilité de la source de données.

Pool de descripteurs de fichiers

Si vos fichiers native TAB ne changent pas souvent, définissez la volatilité sur false et utilisez un pool de descripteurs de fichiers qui minimise l'ouverture et la fermeture des fichiers lors des opérations. Cela est uniquement disponible pour les fichiers shapefiles et les fichiers native et seamless TAB non volatils. Pour les tables non volatiles, des descripteurs de fichiers sont libérés du pool avant d'effectuer toute opération Insert, Update ou Delete.

Le pool de descripteur de fichiers est activé par défaut. La configuration du pool de descripteurs de fichiers est effectuée via le fichier tab-file-handle-pool.properties, qui se trouve dans le dossier \server\modules\spatial. Parmi les propriétés figurent le nombre maximal de descripteurs pouvant être alloués au pool (maxTotal), le nombre maximal de descripteurs alloués par fichier (maxTotalPerKey) et la durée minimale pendant laquelle un descripteur de fichier peut résider dans le pool sans être utilisé avant d'être fermé (minEvictableIdleTimeMillis). Les statistiques du cache de descripteurs de fichiers des fichiers native TAB peuvent être affichées dans la console JMX (pour plus d'informations, voir Surveillance des statistiques de mise en cache des descripteurs de fichiers à l'aide de JMX Console dans la section Administration du Guide Spectrum Spatial).

Pour désactiver le pool de descripteurs de fichiers, ouvrez le fichier \server\modules\spatial\pool-tab.properties et définissez tab.cache.enabled sur false. Pour le paramètre prenne effet, vous devez redémarrer le serveur. Sinon, vous pouvez utiliser la console JMX pour désactiver le pool de descripteurs de fichiers sans redémarrer le serveur et vider le cache de descripteurs de fichiers.