Partager via

Fonction JetInit

  • Article

S’applique à : Windows | Windows Server

Fonction JetInit

La fonction JetInit place le moteur de base de données dans un état où il peut prendre en charge l’utilisation des fichiers de base de données par l’application. Le moteur doit déjà être correctement configuré pour l’initialisation à l’aide de JetSetSystemParameter. La récupération sur incident de base de données est effectuée automatiquement dans le cadre du processus d’initialisation.

JET_ERR JET_API JetInit(
  __in_out_opt  JET_INSTANCE* pinstance
);

Paramètres

pinstance

Instance à utiliser pour cet appel.

Pour Windows 2000, ce paramètre est ignoré et doit toujours être NULL.

Pour Windows XP et versions ultérieures, l’utilisation de ce paramètre dépend du mode de fonctionnement du moteur. Si le moteur fonctionne en mode hérité (mode de compatibilité Windows 2000) où une seule instance est prise en charge, ce paramètre peut être NULL ou être défini sur une mémoire tampon de sortie valide qui retourne le handle de instance global créé en tant qu’effet secondaire de l’initialisation. Cette mémoire tampon de sortie doit être définie sur NULL ou JET_instanceNil. Ce handle instance peut ensuite être passé à n’importe quelle autre fonction qui utilise un instance. Si le moteur fonctionne en mode multi-instance, ce paramètre doit être défini sur une mémoire tampon d’entrée valide qui contient le handle instance retourné par la fonction JetCreateInstance instance en cours d’initialisation.

Notes

Un instance doit être initialisé avec un appel à JetInit avant de pouvoir être utilisé par autre chose que JetSetSystemParameter.

Un instance est détruit par un appel à la fonction JetTerm, même si cette instance n’a jamais été initialisée à l’aide de JetInit. Une instance est l’unité de récupération du moteur de base de données. Il contrôle le cycle de vie de tous les fichiers utilisés pour protéger l’intégrité des données dans un ensemble de fichiers de base de données. Ces fichiers incluent le fichier de point de contrôle et les fichiers journaux des transactions.

Le nombre maximal d’instances pouvant être créées à tout moment est contrôlé par JET_paramMaxInstances, qui peut être configuré par un appel à JetSetSystemParameter. Lorsque le moteur de base de données est initialisé pour la première fois, JetInit crée un ensemble initial de fichiers pour prendre en charge ce instance. Ces fichiers incluent un fichier de point de contrôle (nommé <JET_paramBaseName>. CHK), un ensemble de fichiers journaux des transactions réservés (nommé RES1. LOG et RES2. LOG), un fichier journal des transactions initial (nommé <JET_paramBaseName>. LOG) et un fichier de base de données temporaire (nommé selon JET_paramTempPath). Si JET_paramRecovery est défini sur « Désactivé », le fichier de point de contrôle et les fichiers journaux ne sont pas créés. Si JET_paramMaxTemporaryTables est défini sur zéro, le fichier de base de données temporaire n’est pas créé. Ces fichiers représentent l’encombrement sur disque d’un instance et doivent être gérés avec précaution. Si ces fichiers sont endommagés individuellement ou les uns par rapport aux autres, les données stockées dans les bases de données associées à l’instance peuvent être perdues.

Lorsque le moteur de base de données est initialisé avec un ensemble existant de fichiers journaux des transactions, ces fichiers sont inspectés pour voir si l’incarnation précédente de l’instance a souffert d’un plantage. Si un incident est détecté, la récupération d’incident est automatiquement effectuée. Ce processus reconstruit les bases de données attachées à l’instance pendant l’incarnation précédente du moteur et enregistre les modifications dans les fichiers de base de données. Le résultat sera des bases de données cohérentes avec les transactions. Il est possible que ce processus prenne un certain temps si le nombre de fichiers journaux de transactions à relire par rapport aux bases de données est important.

En raison du fait que JetInit effectue une récupération sur incident, il est possible que presque n’importe quelle erreur du moteur de base de données soit retournée en cas de défaillance. Dans la pratique, la plupart des erreurs observées dans le déploiement appartiennent à deux catégories : l’altération des données et la mauvaise gestion des fichiers. L’altération des données se manifeste le plus souvent dans les erreurs suivantes ou similaires :

  • JET_errReadVerifyFailure

  • JET_errLogFileCorrupt

  • JET_errCheckpointCorrupt

Ces erreurs sont presque toujours dues à des problèmes matériels et ne peuvent donc pas être évitées. La mauvaise gestion des fichiers se manifeste le plus souvent dans les erreurs suivantes ou similaires :

  • JET_errMissingLogFile

  • JET_errAttachedDatabaseMismatch

  • JET_errDatabaseSharingViolation

  • JET_errInvalidLogSequence

Si la récupération est en cours d’exécution sur un ensemble de journaux, pour lesquels toutes les bases de données ne sont pas présentes (ce qui renvoie l’erreur JET_errAttachedDatabaseMismatch dans des circonstances normales), et que le client souhaite que la récupération se poursuive malgré les bases de données manquantes, la JET_ bitReplayIgnoreMissingDB peut être utilisée pour poursuivre la récupération des bases de données disponibles. Ces erreurs sont évitables par l’application. L’application doit veiller à protéger le dépôt de ces fichiers contre toute manipulation par des forces externes telles que l’utilisateur ou d’autres applications. Si l’application souhaite détruire entièrement un instance, tous les fichiers associés à l’instance doivent être supprimés. Il s’agit notamment du fichier de point de contrôle, des fichiers journaux des transactions et de tous les fichiers de base de données attachés au instance.

La fonction JetInit se comporte différemment, en ce qui concerne les fichiers de base de données attachés au instance, entre Windows 2000 et versions ultérieures.

Windows 2000 : Dans Windows 2000, toute base de données attachée au instance au cours d’une incarnation précédente de cette instance reste attachée au instance une fois que JetInit s’est correctement terminé. Il n’est pas nécessaire d’appeler JetAttachDatabase après JetInit pour assurer l’accès ultérieur à la base de données. Si la fonction JetAttachDatabase est appelée après la fonction JetInit , l’avertissement JET_wrnDatabaseAttached est retourné. Cet avertissement indique que la pièce jointe de base de données a été conservée et peut être ignorée.

Windows XP : Dans Windows XP et les versions ultérieures, toutes les bases de données sont automatiquement détachées de la instance par JetInit. Cela signifie que JetAttachDatabase doit toujours être appelé après JetInit dans ce cas.

Toute application écrite pour s’exécuter sur Windows 2000 et sur les versions ultérieures doit toujours appeler JetAttachDatabase après JetInit. Si l’application s’exécute sur Windows 2000, elle doit s’attendre à voir JET_wrnDatabaseAttached dans certains cas. Pour plus d’informations , consultez JetAttachDatabase .

Spécifications

Condition requise Valeur

Client

Nécessite Windows Vista, Windows XP ou Windows 2000 Professionnel.

Serveur

Nécessite Windows Server 2008, Windows Server 2003 ou Windows 2000 Server.

En-tête

Déclaré dans Esent.h.

Bibliothèque

Utilisez ESENT.lib.

DLL

Nécessite ESENT.dll.

Voir aussi

Fichiers du moteur de stockage extensibles
JET_ERR
JET_GRBIT
JET_INSTANCE
JET_paramMaxTemporaryTables
JET_paramRecovery
JetAttachDatabase
JetCreateInstance
JetInit3
JetSetSystemParameter