Connexion aux bases de données Microsoft Access via ADO + ODBC

Articles et ressources connexes

• KB-LJW-DB-101 : Impact des types de curseurs ADO sur un driver ODBC en ASP

Drivers Microsoft Access installés sur nos serveurs ASP Classic

Les Drivers ODBC et Provider OLEDB natifs vous permettant de vous connecter aux bases de données Microsoft Access sont installés sur nos hébergements mutualisés ASP Classic, et sont disponibles en 32 bits et 64 bits :

•  {Microsoft.Jet.OLEDB.4.0}
•  {Microsoft.ACE.OLEDB.12.0}
•  {Microsoft Access Driver (*.mdb)}
•  {Microsoft Access Driver (*.mdb, *.accdb)}

Que sont les bases Microsoft Access

Les bases Microsoft Access sont des bases de données relationnelles stockées dans un fichier .mdb ou .accdb. Elles reposent sur le moteur historique Jet Database Engine (Jet.OLEDB), et désormais Access Database Engine (ACE.OLEDB 12/14/16).

Fréquemment utilisées en développement ASP Classic, les bases Access sont avant tout une source de données relationnelle simple car accessible sans serveur de base de données dédié. Vous pouvez l'interroger via le langage SQL, avec parfois quelques adaptations et spécificités du dialecte SQL pour Access .

Sur le plan technique, Access organise les données en tables, relations, index et requêtes, de manière comparable aux autres SGBD. L'accès à vos bases Access s'affectue en ASP Classic typiquement via ADO (ActiveX Data Objects), en utilisant soit un fournisseur OLE DB (par exemple Microsoft.Jet.OLEDB.4.0 ou Microsoft.ACE.OLEDB.12.0), soit le Driver ODBC fourni par Microsoft Microsoft Access Driver (.mdb, .accdb).

Les bases Access sont adaptées aux sites à trafic et volume de données intermédiaire, du fait qu'il n'existe pas de séparation stricte entre moteur, stockage et accès concurrent. Tous ces rôles sont encapsulés dans un seul fichier : connexions, objets Recordset, requêtes SQL, transactions.

Comment gérer et administrer les bases Access

Du fait que les bases de données Microsoft Access sont fournies sous forme de fichier indépendant, leur utilisation est simple. Il suffit de placer un fichier .mdb ou .accdb dans un répertoire de votre site internet, et votre code ASP possède les droits d'y accéder. Selon la formule d'hébergement dédié ou mutualisé dont vous disposez, vous pouvez utiliser un nombre illimité de bases .mdb ou .accdb.

La gestion des bases Access s'effectue dans la plupart des cas par transfert FTP, et par gestion directe depuis des pages codées en ASP Classic. Les pages destinées à la face publique de votre site internet ont en général vocation à lire les données (avec quelques cas d'écriture), tandis que vos pages de type "Administrateur/Backoffice/Manager/Intranet" vous permettent des opérations d'écriture et mise à jour de vos données en tant qu'exploitant du site.

La gestion à distance vos bases de données depuis l'application Microsoft Access installée sur votre ordinateur est techniquement possible, mais n'est en général fiable que depuis un réseau local. Les conditions d'une base Access située sur un serveur web distant ne sont pas adaptées à cette technique, ou alors avec soit des risques de corruption de données importants, soit des périodes de blocage rendant votre base inaccessible pour les accès concurrents côté site web public, ou des verrouillages fantômes et des temps de réponse imprévisibles.

Ces limitations sont inhérentes au fait que Microsoft Access est un moteur de base de données basé sur un fichier unique, et pas un serveur de bases de données. L'accès aux bases n'est donc possible qu'avec un très faible concurrence de connexions, et toujours au prix d'un verrouillage de la base. Un accès distant n'est donc pas un choix fiable d'un point de vue opérationnel.

Comment accéder aux bases Access depuis ASP Classic

La connexion à vos bases de données Microsoft Access depuis votre site ASP Classic s'effectue au travers d'un Provider OLEDB natif, ou bien d'un Driver ODBC fourni à cet effet par Microsoft. Les différences entre OLE DB et ODBC sont présentées dans cette section.

La méthode de connexion à privilégier dépend principalement du bitness (32 bits ou 64 bits) de votre Application Pool IIS. La règle de choix principale est la suivante :

•  {Microsoft.Jet.OLEDB.4.0} :
  Ancien provider OLEDB adapté aux connections 32 bits
•  {Microsoft.ACE.OLEDB.12.0} :
  Provider OLEDB actuel adapté aux connections 64 bits
•  {Microsoft Access Driver (*.mdb)} :
  Solution de repli si OLEDB ne convient pas, disponible en 32-bits
•  {Microsoft Access Driver (*.mdb, *.accdb)} :
  Solution de repli si OLEDB ne convient pas, disponible en 64-bits

Le tableau suivant vous présente les différentes méthodes d'accès à vos bases Access :

Connexion directe sans DSN via un Driver ODBC ou Provider OLE DB

Lorsque vous établissez une connexion à votre base Microsoft Access via un Driver ODBC depuis votre code ASP, vous établissez une connexion dite "DSN-Less". Vous n'avez dans ce cas pas besoin de spécifier Provider=MSDASQL (Microsoft OLE DB provider for ODBC) dans votre chaîne de connexion : ce provider OLE DB par défaut pour les Drivers ODBC est implicitement utilisé par ADO.

Une exception à noter : vous devrez probablement ajouter Provider=MSDASQL; DSN=MonDSN; à votre chaîne de connexion si vous établissez votre connexion via un DSN.

Microsoft.Jet.OLEDB.4.0

Microsoft.Jet.OLEDB.4.0 est le fournisseur OLE DB permettant à ADO d'accéder au Jet Database Engine , le moteur historique de Microsoft Access. Il fonctionne exclusivement avec des fichiers .mdb et uniquement en 32 bits. Il a été longtemps privilégié en ASP Classic pour les sites exécutés dans un Pool d'Application IIS réglé en 32-bit. Sur un Pool 64-bits, il doit être substitué par Microsoft.ACE.OLEDB.12.0.

Jet est encore installé sur la majorité des serveurs d'hébergement web pour assurer la compatibilité des très nombreux site web ASP exécutés sur des Pools d'Application IIS en 32-bit. Son fonctionnement est stable sur des applications historiques. Notez qu'il n'est toutefois plus maintenu et impose des contraintes notables en termes de concurrence et de fiabilité. La migration en 64-bits est à privilégier.

L'exemple suivant vous montre comment établir une connexion à une base Access via le Provider JET OLE DB en 32-bits :

<%
'Établir la connexion à la base Access via le Provider JET OLE DB 4
'Disponible pour les Application Pool en 32-bits
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open "Provider=Microsoft.Jet.OLEDB.4.0; DATA SOURCE=base.mdb;"
%>

Si vous souhaitez effectuer des opérations qui nécessitent un accès exclusif à votre base Access, ajoutez le paramètre Mode=Share Exclusive; à votre chaîne de connexion. Assurez-vous de ne pas bloquer de manière prolongée votre base avec ce procédé, afin que les pages publiques de votre site puissent se connecter à la base.

Microsoft.ACE.OLEDB.12.0

Microsoft.ACE.OLEDB.12.0 est le fournisseur OLE DB exposant le Access Database Engine  (ACE), successeur officiel de Jet. Il prend en charge les formats .accdb et .mdb et fonctionne en 64 bits (et/ou en 32-bits si installé). Il est destiné à remplacer Jet dans les accès programmatiques à Access via ADO depuis vos pages ASP Classic.

ACE n'est pas un simple renommage de Jet : c'est un moteur différent et plus récent, avec davantage de types de données et une meilleure compatibilité Unicode. En revanche, il ne transforme pas Access en base serveur : les mêmes limites structurelles persistent.

L'exemple suivant vous montre comment établir une connexion à une base Access via le Provider ACE OLE DB en 64-bits :

<%
'Établir la connexion à la base Access via le Provider ACE OLE DB 12 (ou 14, ou 16)
'Disponible pour les Application Pool en 64-bits
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open "Provider=Microsoft.ACE.OLEDB.12.0; DATA SOURCE=base.mdb;"
%>

Si votre base est protégée par un mot de passe, spécifiez-le dans votre chaîne de connexion avec le paramètre Jet OLEDB:Database Password=yourPassword;. Cette méthode nécessite dans certains cas que vous utilisiez un mot de passe ne contenant pas de caractères spéciaux, et d'une longueur n'excédant pas 14 caractères. Enfin, certaines base encryptés avec Access 2010 - 2013 peuvent ne pas fonctionner; vous devez dans ce cas choisir l'encryptage de type Access 2007.

Microsoft Access Driver (*.mdb, *.accdb)

Le Microsoft Access Driver (.mdb, .accdb) est un pilote ODBC historiquement conçu pour permettre l'accès aux bases Access via le protocole ODBC. Toutefois, lorsqu'il est utilisé avec ADO, les couches suivantes sont empilées : ADO > ODBC > Jet/ACE. Utiliser ODBC dans ce contexte est techniquement inférieur dans le sens où cela ajoute une couche d'abstraction inutile qui dégrade légèrement les performances. Depuis votre code ASP Classic, un Provider OLE DB (Jet/ACE) est à privilégier car plus direct et mieux intégré.

L'exemple suivant vous montre comment établir une connexion à une base Access via le Driver ODBC en 32-bits :

<%
'Établir la connexion à la base Access via le Driver ODBC
'Disponible pour les Application Pool en 32-bits
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open "Driver={Microsoft Access Driver (*.mdb)}; Dbq=base.mdb; Uid=Admin; Pwd=;"
%>

L'exemple suivant vous montre comment établir une connexion à une base Access via le Driver ODBC en 64-bits :

<%
'Établir la connexion à la base Access via le Driver ODBC
'Disponible pour les Application Pool en 64-bits
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open "Driver={Microsoft Access Driver (*.mdb, *.accdb)}; Dbq=base.accdb; Uid=Admin; Pwd=;"
%>

Si vous souhaitez effectuer des opérations qui nécessitent un accès exclusif à votre base Access, ajoutez le paramètre Exclusive=1; à votre chaîne de connexion. Assurez-vous de ne pas bloquer de manière prolongée votre base avec ce procédé, afin que les pages publiques de votre site puissent se connecter à la base.

Connexion via un DSN

La connexion à une base Microsoft Access via DSN est possible en faisant usage du Driver ODBC, mais pas du Provider OLE DB natif.

Si vous disposez d'un hébergement mutualisé fourni par Le Juste Web, vous pouvez vous connecter à une base de données Access via un DSN en procédant de la manière suivante :

1. Connectez-vous à Plesk
2. Rendez-vous dans l‘onglet « Dashboard » puis cliquez sur « ODBC Data Sources »
3. Cliquez sur le bouton « Add ODBC DSN »
4. Saisissez les informations d'authentification à votre base de données Access ainsi que les paramètres afférents à cette connexion ODBC.
5. Dans votre code ASP, vous pouvez désormais vous connecter à ce DSN ODBC en utilisant l'une des méthodes suivantes :
   ASP CLASSIC

   <%
   'Établir la connexion à la base Access via un DSN
   'Disponible pour les Application Pool en 32-bits et 64-bits
   Dim objConn
   Set objConn = Server.CreateObject("ADODB.Connection")
   objConn.CursorLocation = 3 'adUseClient (cf. "adovbs.inc")
   
   'Méthode 1
   objConn.ConnectionString = "DSN=DSNname;Uid=Username;Pwd=Password"
   objConn.Open
   
   ''Méthode 2 (alternative)
   'objConn.Open "DSNname", "Username", "Password"
   %>

   
   

Dans nos hébergements mutualisés, vous pouvez à tout moment ajuster le bitness du Application Pool dans Plesk dans l'onglet « Hosting & DNS > Dedicated IIS Application Pool for Website » sur l'option « Enable 32-bit applications ».

Conseils et cas particuliers avec Microsoft Access

Microsoft Access est un système simple qui offre une mise en œuvre rapide et peu coûteuse, ce qui en fait un choix naturel et adapté dans de nombreux cas pour des sites ASP Classic. Toutefois, du fait qu'il s'agit d'un système de bases de données par fichier sans serveur, certaines limites structurelles importantes pour un usage sur votre site web sont à prendre en compte lors de son utilisation.

La gestion de la concurrence est rudimentaire, les performances peuvent chuter lors d'accès simultanés, et le risque de corruption du fichier augmente sous de fortes charges ou de nombreuses requêtes. Le dialecte SQL utilisé par Jet/ACE diffère du standard SQL strict, ce qui peut compliquer la rédaction de requêtes avancées et diminuer la portabilité de la base.

Si vous rencontrez une quelconque difficulté, n'hésitez pas à nous contacter.

Corruption de base & Backups

Les risques de corruption de données d'une base Access sont réels. Les bases Access reposent sur un fichier unique (.mdb / .accdb) accédé directement par le moteur Jet ou ACE. Cette architecture expose la base à des corruptions en cas d'écriture interrompue, comme par exemple un arrêt brutal du serveur IIS, un crash applicatif, une coupure réseau, ou un verrouillage concurrent mal géré, ou lorsqu'elles sont exploitées sur des sites qui reçoivent un trafic parfois conséquent, ou bien encore un très grand nombre de requêtes sur de courtes périodes. Plus les écritures sont fréquentes et simultanées, plus le risque augmente. La corruption de votre base peut être partielle (certaines tables ou index illisibles), ou totale, rendant la base inutilisable.

Même une base "bien conçue" peut se corrompre : certains facteurs doivent vous alerter de problèmes de corruption imminents :

•  Multiples accès concurrents en écriture
•  Bases volumineuses ou proches de leur limite de 2 Go
•  Absence de compactage régulier
•  Code ASP ne fermant pas correctement les connexions et recordset

Les sauvegardes régulières sont indispensables. Il s'agit en effet du seul moyen fiable de récupération des données après corruption sévère de votre base. Conservez plusieurs sauvegardes historiques sur une période de rétention (par exemple 1 semaine ou 1 mois) suffisamment longue pour vous permettre d'identifier le problème de corruption et restaurer le jeu de données qui vous convient.

Les outils de réparation intégrés à l'application Microsoft Access peuvent parfois restaurer une base, mais sans aucune garantie d'intégrité des données. Les backups que vous réalisez ne servent pas uniquement aux corruptions de données, mais également aux erreurs humaines qui peuvent survenir lorsque vous codez ou intervenez sur votre base (ex. suppression accidentelle, mise à jour incorrecte). Retenez que "faire des sauvegardes de temps en temps" ou uniquement avant une opération risquée est insuffisant.

Suivez les bonnes pratiques de sauvegarde suivantes :

•  Sauvegardez de manière automatisée et régulière (quotidienne au minimum)
•  Sauvegardez hors ligne (lorsque base fermée + avec accès exclusif)
•  Conservez de plusieurs versions (rotation)
•  Testez périodiquement la viabilité de vos bases sauvegardées

Curseur par défaut

ADO ne laisse jamais la main au curseur par défaut du Driver ODBC, et spécifie à-minima 0=adOpenForwardOnly. Cela signifie concrètement que même si vous ne spécifiez pas la propriété rs.CursorType, le curseur par défaut du Driver ODBC Microsoft Access ne s'applique pas.

Référez-vous à notre article KB-LJW-DB-101 à ce sujet.

Taille maximale de 2 Go

Une base Microsoft Access possède théoriquement une taille maximale de 2 Go par fichier (.mdb ou .accdb). Cette limite inclut toutes les données, mais aussi les index, les objets système, les tables temporaires et l'espace inutilisé interne.

En pratique, une base Access devient instable bien avant 2 Go. Les performances se dégradent fortement à partir de 1 ~ 1,2 Go, surtout en présence d'écritures fréquentes. La limite opérationnelle réaliste se situe donc plutôt autour des ~1 Go. Les opérations comme les requêtes complexes, les mises à jour massives ou la création d'index nécessitent de l'espace temporaire, ce qui peut provoquer des erreurs même si la taille finale de votre base reste inférieure à 2 Go.

Quelques points fréquemment mal compris concernant les bases Access :

•  Supprimer des données ne réduit pas la taille du fichier sans compactage ultérieur.
•  Les champs de type OLE Object / Attachment consomment très rapidement l'espace. Stockez plutôt ces données binaires dans des fichiers sur le disque.
•  Les tables temporaires et les requêtes de tri peuvent échouer par manque d'espace interne, sans que le disque soit plein.
•  Le moteur Jet/ACE ne répartit pas les données sur plusieurs fichiers. Vous ne disposez que d'un seul fichier par base Access.

Cette limite architecturale inhérente aux bases Microsoft Access les rend rapidement inadaptées aux bases volumineuses ou à croissance continue. Quelques-unes des stratégies les plus fréquemment utilisées pour circonvenir à ce problème de taille sont par exemple :

•  Séparer les données en plusieurs bases (partitionnement manuel). Cela présente rapidement l'inconvénient de devoir gérer manuellement plusieurs fichiers de bases, ce qui augmente les risques de confusion.
•  Archiver régulièrement les données anciennes dans d'autres bases de stockage "froides"
•  Migrer vers un réel serveur de base de données (par exemple MariaDB ou SQL Server) lorsque que la taille devient structurellement critique

Compactage et maintenance

Au fil du temps, la taille de votre base Access croit. À chaque modification de données, de l'espace vide est laissé dans la base et n'est pas purgé. Le compactage d'une base Microsoft Access est une opération de maintenance qui réécrit entièrement le fichier de base de données (.mdb ou .accdb). Elle consiste à supprimer l'espace laissé par les enregistrements supprimés ou modifiés, et à réorganiser les pages de données et reconstruire certains index.

Le compactage n'est pas une opération de secours optionnelle, mais bien une pratique que vous devez intégrer au cycle de vie de votre application ASP. Notez toutefois que le compactage ne corrigera pas une mauvaise architecture et n'améliore pas la gestion de la concurrence, cette dernière étant inhérente au moteur en lui-même. Les raisons qui doivent vous pousser à systématiquement compacter votre base de manière régulière sont les suivantes :

•  Réduction de la taille du fichier
•  Amélioration des performances (requêtes, index)
•  Diminution du risque de corruption
•  Restauration de la cohérence interne après de nombreuses opérations d'écrite de type INSERT, UPDATE, DELETE

En pratique, le moteur Jet ou ACE crée une nouvelle copie interne de la base, y recopie uniquement les données valides, puis remplace le fichier original. L'espace disque est ainsi récupéré et la structure logique est réoptimisée. L'opération de compactage ouvre la base en mode accès exclusif, ce qui rend la base inaccessible durant cette opération. Sur les bases de taille importante cela peut la bloquer durant plusieurs minutes, en particulier si aucun compactage n'a récemment été effectué. Planifiez donc toujours ce compactage hors période d'utilisation.

Nous vous recommandons d'effectuer un compactage de votre base Microsoft Access :

•  Pour les applications peu modifiées : chaque mois
•  Pour les applications avec des écritures fréquentes : chaque semaine
•  Pour les applications très actives : plus fréquemment et après des traitements lourds

Vous pouvez effectuer ce compactage de manière manuelle ou automatisée via un script :

•  Via Microsoft Access : Via le Menu "Outils de base de données > Compacter et réparer"
•  Via un script ASP ou VBScript planifié : Utilisez le moteur Jet ou ACE pour compacter la base

Les codes source suivants (VBScript ou ASP) vous montrent comment compacter votre base Access de manière régulière :

•  Si vous utilisez un Pool d'Applications IIS 64-bits :
  
  ASP CLASSIC

  <%
  'Forcer une valeur numérique sur X digits, préfixée par des 0 (ex. 5 => 05)
  Function Num2Digits(data, numdigits)
     Num2Digits = Right(String(numdigits, "0") & CStr(data), 2)
  End Function 'Num2Digits
  
  'Déplacer/renommer un fichier
  Sub MoveRenameFile(sSrc, sDest)
     Dim fso, f
     Set fso = Server.CreateObject("Scripting.FileSystemObject")
        fso.MoveFile sSrc, sDest
     Set fso = Nothing : fso = Empty
  End Sub 'MoveRenameFile
  
  'Définir le chemin vers la base Access source
  '(les chemins UNC sont possibles mais déconseillés avec Access => risques de corruption)
  Dim sFilePathFrom : sFilePathFrom = Server.MapPath("/data/base.accdb")
  
  Dim sDateTimeStamp : sDateTimeStamp = "_" & Year(Now()) & Num2Digits(Month(Now()),2) & Num2Digits(Day(Now()),2) & "_" & Num2Digits(Hour(Now()),2) & Num2Digits(Minute(Now()),2) & Num2Digits(Second(Now()),2)
  
  'Définir le chemin vers la base Access compactée
  '(les chemins UNC sont possibles mais déconseillés avec Access => risques de corruption)
  Dim sFilePathTo : sFilePathTo = Server.MapPath("/data/base_compactee" & sDateTimeStamp & ".accdb")
  
  'Définir les chaines de connexion
  Dim sdbConnFrom, sdbConnTo
  sdbConnFrom = "Provider=Microsoft.ACE.OLEDB.12.0; Data Source=" & sFilePathFrom
  sdbConnTo   = "Provider=Microsoft.ACE.OLEDB.12.0; Data Source=" & sFilePathTo
  
  'Activer la gestion d'erreurs
  Err.Clear
  On Error Resume Next
  
  'Compacter la base Access depuis "Data Access Objects" (64-bits)
  Dim oDAO
  Set oDAO = Server.CreateObject("DAO.DBEngine.120")
  oDAO.CompactDatabase sdbConnFrom, sdbConnTo
  
  if (Err.Number <> 0) then
     Response.Write "Erreur lors du compactage de """ & sFilePathFrom """ : " & Err.Number & " - " & Err.Description
  else
     'Renommer la base compactée vers la Production
     MoveRenameFile sFilePathTo, sFilePathFrom
  end if
  
  'Désactiver la gestion d'erreurs
  Err.Clear
  On Error Goto 0
  %>

  
  
•  Si vous utilisez un Pool d'Applications IIS 32-bits :
  
  ASP CLASSIC

  <%
  'Forcer une valeur numérique sur X digits, préfixée par des 0 (ex. 5 => 05)
  Function Num2Digits(data, numdigits)
     Num2Digits = Right(String(numdigits, "0") & CStr(data), 2)
  End Function 'Num2Digits
  
  'Déplacer/renommer un fichier
  Sub MoveRenameFile(sSrc, sDest)
     Dim fso, f
     Set fso = Server.CreateObject("Scripting.FileSystemObject")
        fso.MoveFile sSrc, sDest
     Set fso = Nothing : fso = Empty
  End Sub 'MoveRenameFile
  
  'Définir le chemin vers la base Access source
  '(les chemins UNC sont possibles mais déconseillés avec Access => risques de corruption)
  Dim sFilePathFrom : sFilePathFrom = Server.MapPath("/data/base.mdb")
  
  Dim sDateTimeStamp : sDateTimeStamp = "_" & Year(Now()) & Num2Digits(Month(Now()),2) & Num2Digits(Day(Now()),2) & "_" & Num2Digits(Hour(Now()),2) & Num2Digits(Minute(Now()),2) & Num2Digits(Second(Now()),2)
  
  'Définir le chemin vers la base Access compactée
  '(les chemins UNC sont possibles mais déconseillés avec Access => risques de corruption)
  Dim sFilePathTo : sFilePathTo = Server.MapPath("/data/base_compactee" & sDateTimeStamp & ".mdb")
  
  'Définir les chaines de connexion
  Dim sdbConnFrom, sdbConnTo
  sdbConnFrom = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & sFilePathFrom
  sdbConnTo   = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & sFilePathTo
  
  'Activer la gestion d'erreurs
  Err.Clear
  On Error Resume Next
  
  'Compacter la base Access depuis "Jet and Replication Objects" (32-bits)
  Dim oJRO
  Set oJRO = Server.CreateObject("JRO.JetEngine")
  oJRO.CompactDatabase sdbConnFrom, sdbConnTo
  
  ''OU BIEN
  ''Compacter la base Access depuis "Data Access Objects" (32-bits)
  'Dim oDAO
  'Set oDAO = Server.CreateObject("DAO.DBEngine.36")
  'oDAO.CompactDatabase sdbConnFrom, sdbConnTo
  
  if (Err.Number <> 0) then
     Response.Write "Erreur lors du compactage de """ & sFilePathFrom """ : " & Err.Number & " - " & Err.Description
  else
     'Renommer la base compactée vers la Production
     MoveRenameFile sFilePathTo, sFilePathFrom
  end if
  
  'Désactiver la gestion d'erreurs
  Err.Clear
  On Error Goto 0
  %>

  
  

  La version du DAO.DBEngine à instancier dépend de la version des Drivers installés sur le serveur. Nos hébergements mutualisés fournissent la version 12.

  Moteur	Provider OLE DB	DAO DBEngine
  Jet 4.0	Microsoft.Jet.OLEDB.4.0	DAO.DBEngine.36
  ACE 2007	Microsoft.ACE.OLEDB.12.0	DAO.DBEngine.120
  ACE 2010	Microsoft.ACE.OLEDB.14.0	DAO.DBEngine.140
  ACE 2016+	Microsoft.ACE.OLEDB.16.0	DAO.DBEngine.160

Si une connexion est encore ouverte (fichier *.ldb ou *.laccdb encore présent) le compactage échouera et une erreur COM+ sera levée. Il convient donc d'implémenter ce code source de préférence dans une boucle qui teste l'accès exclusif avec Set dbe = Server.CreateObject("DAO.DBEngine.36") : Set db = dbe.OpenDatabase("C:\data\base.mdb", True) puis d'effectuer une pause/sleep de 10 secondes avant la prochaine tentative, ou bien de planifier votre tâche à un moment de la journée ayant le moins d'activité sur votre base. D'autres stratégies avancées impliquent l'arrêt du Pool d'Applications IIS depuis VBScript par exemple. Cela nécessite toutefois des droits d'accès élevés sur le serveur. Prenez contact avec nous si vous avez besoin de telles techniques.

Gestion du verrouillage (fichiers *.ldb et *.laccdb)

Les fichiers .ldb et .laccdb sont des fichiers de verrouillage utilisés par Microsoft Access pour gérer l'accès concurrent à la base de données et sont de ce fait indissociables de son fonctionnement interne. Lorsqu'un utilisateur ouvre une base via le moteur Jet/ACE, un fichier .ldb ou .laccdb est créé automatiquement par Microsoft Access. Le rôle principal de ce fichier est de gérer les verrous (locking), identifier les utilisateurs connectés, et éviter les écritures concurrentes incompatibles. Ce fichier ne contient pas de données en soi, est créé dans le même dossier que la base, et disparaît lorsque le dernier utilisateur ferme la base.

Le verrouillage dans Access fonctionne par pages de 2 Ko ou 4 Ko selon la version, et non pas par ligne à la différence des autres systèmes de bases de données fonctionnant à base d'un serveur, tels que MariaDB. Les conséquences sont qu'une seule modification peut bloquer plusieurs enregistrements, mais aussi que les performances peuvent rapidement chuter, et enfin que des conflits fréquents peuvent se présenter.

Lors d'un crash du Pool d'Application exécutant votre application ASP, ce fichier de verrou peut peut rester "orphelin". Sa présence indique alors une fermeture incorrecte, et empêche l'accès exclusif. Il vous empêche également typiquement d'écrire/écraser le fichier de base de données via FTP, car il est considéré comme "bloqué" (locked).

Access n'est pas conçu pour la concurrence réelle. Ce fichier de verrou est un palliatif pour permettre de la simuler dans des conditions de faible trafic, mais constitue en réalité un verrouillage "grossier" extrêmement sensible extrême aux interruptions réseau et avec une quasi absence de tolérance aux pannes.

Si vous devez supprimer un fichier .ldb ou .laccdb résiduel :

•  Ne le supprimez jamais pendant que la base est ouverte
•  Ne copiez pas une base pendant qu'un .ldb existe
•  Si la suppression est impossible :
  • Sur un hébergement mutualisé : vous devez recycler le Pool d'Application depuis Plesk dans l'onglet « Hosting & DNS > Dedicated IIS Application Pool for Website », puis attendre plusieurs minutes que l'accès au fichier soit libéré : soit il disparaitra de lui-même, soit vous devrez (et pourrez enfin) le supprimer manuellement.
  • Sur un serveur dédié : vous pouvez directement tuer le processus w3wp.exe associé à votre Pool d'Applications IIS : le fichier sera libéré et vous pourrez immédiatement le supprimer. L'accès à la base sera également possible, ce qui vous permettra de l'écraser via FTP au besoin.

Des fichiers de locking résiduels et orphelins très fréquents sont des indices que le Pool d'Application IIS a planté. Il est alors temps de vous pencher sur votre code source ou le schema de la base pour comprendre pourquoi. Une migration vers un système de bases de données plus robuste tel que MariaDB est également à envisager si vous rencontrez trop fréquemment ce genre de problèmes.

Migration vers MariaDB

Il peut arriver que vous touchiez d'une manière ou d'une autre aux limites de microsoft Access. À ce moment se pose la question de migrer vers un système de base de données plus robuste. La solution qui pourrait sembler la plus évidente de prime abord serait Microsoft SQL Server. Pourtant, ce produit est extrêmement différent de Access, et réellement beaucoup plus complexe à maîtriser, en plus d'avoir un coût de licence conséquent. Nous le fournissons uniquement sur nos serveurs dédiés pour ces raisons. Une transition vers MariaDB est plus adaptée dans la majorité des cas.

Migrer de Microsoft Access vers MariaDB devient pertinent dès que votre application révèle les symptômes suivants : écritures concurrentes fiables non bloquantes, montée en charge poussive, besoin de sauvegardes et restaurations fiables, exigences de disponibilité, ou volonté de sortir des limites structurelles d'Access (taille, verrouillage, risque de corruption).

MariaDB apporte un réel moteur serveur, des transactions robustes, et des fonctionnalités d'accès et de sauvegarde efficaces, tout en restant simple à utiliser lorsque vous avez l'expérience de Microsoft Access. La gestion de la concurrence et de centaines de connexions ou requêtes simultanées est absolument sans comparaison.

Le biais fréquent consiste néanmoins à croire qu'un simple changement de moteur suffira. Il ne s'agit en réalité pas d'un simple "un export/import", mais bien d'une remise à plat contrôlée des données, des requêtes et du processus d'exploitation. Une migration de moteur de bases de données implique un changement du modèle d'exécution (fichier local versus serveur). Elle impacte donc le schéma, les requêtes, et le code ADO. Toutefois, une fois les données importées et vos requêtes ajustées, un changement de Driver ODBC est bien souvent la dernière étape requise.

Nous maîtrisons la méthodologie à suivre pour effectuer une telle migration en douceur et sans rupture de production de votre site ASP. Elle consiste principalement à évaluer les tables, relations, index, requêtes enregistrées, règles de validation, champs calculés, macros, et enfin les requêtes SQL spécifiques Jet/ACE qu'il faudra partiellement réécrire pour être au standard SQL.

Lors de la conception du schéma cible sur MariaDB (types, clés primaires, contraintes, index), il convient de traiter les divergences avec Access, comme par exemple AutoNumber qui devient AUTO_INCREMENT, Oui/Non qui devient TINYINT(1) ou BOOLEAN, ou encore Date/Heure qui devient DATETIME/TIMESTAMP.

Les champs de type Attachment/OLE sont déjà déconseillés avec Microsoft Access, comme dans tout SGBD. Cette migration est l'occasion de les repenser, bien souvent en stockant les données binaires dans un fichier sur le disque. C'est également l'occasion de corriger les anti-modèles fréquents sous Access tels que l'absence de clés, les types trop permissifs ou les données multi-valeurs; migrer à l'identique ne ferait que transférer des problèmes de schema.

Lors de telles migrations nous sommes particulièrement attentifs à la syntaxe spécifique du SQL et de la logique applicative côté ASP ou requêtes enregistrées. Jet/ACE et MariaDB n'ont pas le même dialecte (ex. fonctions de date, concaténation, IIf, Nz, LIKE, TOP, paramètres, gestion des nulls). Pour chaque requête critique il convient d'écrire son équivalent en SQL standard compatible avec MariaDB, puis de valider les résultats sur un jeu de données figé.

Côté ASP Classic, les chaînes de connexion OLE DB Access devront être remplacées par le Driver ODBC MariaDB. Il convient de prêter attention au changement de sémantique transactionnelle, en particulier les curseurs ADO : ce qui "semblait marcher" avec Access (verrouillages implicites) doit devenir explicite avec rs.CursorType pour fiabiliser le fonctionnement de votre code ASP.

Enfin, la phase de transfert de données s'aborde en deux temps : extraction depuis Access vers un format intermédiaire (CSV ou TSV) puis import dans MariaDB avec un contrôle strict des encodages UTF-8, des formats de date et des valeurs nulles. Des contrôles d'intégrité sont à mener, comme par exemple les comptages de lignes, sommes de contrôle, échantillonnage de lignes, et vérification de contraintes. Si la bascule franche de Access vers MariaDB n'est pas envisageable, prévoyez une phase de double écriture ou de synchronisation.

Nous prenons également soin de prévoir des plans de retour en arrière (rollback), en conservant dans le code ASP les anciennes requêtes compatibles Access, et nous opérons la bascule opérationnelle de manière planifiée et structurée.

Retenez enfin que quel que soit le système de base de données, aucun d'entre-eux ne sait éliminer les problèmes provenant du code ASP en lui-même ou du schema (requêtes non indexées, absence de paramètres, logique métier hasardeuse) : tout ceci relève du rôle de l'architecte logiciel que vous êtes !
(et que nous sommes aussi !)

Hébergement ASP Classic

Hébergement ASP Classic et migration vers Windows Server 2025 / 2022 / 2019

Maintenance & développement ASP Classic

Maintenance, support et développement de sites et applications ASP Classic

Audit & configuration de IIS

Audit et amélioration de la configuration de Microsoft® IIS