Gestion des données de type "DATE" avec MySQL et MariaDB

Articles et ressources connexes

• KB-LJW-DB-105 : Connexion aux bases de données MariaDB via ADO + ODBC
• KB-LJW-DB-101 : Impact des types de curseurs ADO sur un driver ODBC en ASP

Les dates et MySQL : un mariage raté

Historiquement, MySQL a toujours privilégié la tolérance à l'erreur plutôt que la rigueur des données. Ce choix a peu à peu conduit à une gestion permissive des dates et heures : acceptation de valeurs invalides (0000-00-00, mois ou jour à zéro), conversions implicites silencieuses, ou encore remplacement automatique de valeurs manquantes. Du fait de cette nature historiquement permissive du moteur MySQL, ces pratiques ne provoquaient pas d'erreurs bloquantes, mais de simples avertissements, souvent ignorés par les développeurs au niveau de la couche applicative ASP. Après tout, tant que ça marche...

Cette permissivité a des conséquences durables, tant sur les données que sur les performances à l'oeuvre pour y accéder, voire sur leur qualité. Nombreux sont les schémas ayant été conçus pour s'appuyer sur des "dates sentinelles" (0000-00-00 00:00:00) sensées représenter l'absence de valeur, au lieu d'utiliser la seule valeur fiable : NULL.

La conséquence est que de nombreuses interfaces et connecteurs clients (ODBC, PHP, etc.) ont dû implémenter des comportements spécifiques pour gérer ces pseudo-dates incorrectes, soit en les transformant, soit en générant des erreurs d'exécution. Au-delà de la non-conformité technique, ces valeurs posent de manière plus frontale la réelle question de leur nature : signifient-elles "inconnu", "non applicable", "erreur" ou "valeur réelle" ? Or, une donnée dont vous ne pouvez pas déterminer la qualité est par essence inexploitable, donc inutile à stocker. Cela va totalement à l'encontre même du fait de la stocker dans une base.

MySQL a tenté de corriger au fil du temps ces dérives originelles en introduisant des modes SQL stricts (sql_mode), des contraintes CHECK réellement appliquées, et une meilleure conformité au standard SQL. Cependant, ces mécanismes restent optionnels et sont arrivés tardivement, laissant de-facto une situation avec de nombreuses bases en production mélangeant encore des comportements hérités (modes permissifs, données historiques invalides) avec des attentes modernes de robustesse.

MariaDB a quant à lui appris des erreurs de MySQL, et pris le parti de ser montre bien plus fiable et conforme aux standard SQL, tout en offrant une certaine permissivité sur demande pour les cas particuliers, afin de pouvoir opérer des transitions graduelles sur les bases de données et bases de code source conséquentes.

Cet article vous fournit des techniques de contournements efficaces pour gérer les cas les plus délicats, ainsi que des bonnes pratiques telles que la définition de schémas stricts, le rejet des dates invalides à l'écriture, la lecture fiable de dates incorrectes, l'usage correct de NULL, ou encore un paramétrage cohérent du serveur et des clients, à savoir le Driver ODBC servant à fournir les données à votre application ASP Classic.

Le moment de l'explosion

Commencez par une profonde inspiration : dans l'immense majorité des cas, si votre schéma et vos données sont correctes, votre code ASP Classic se comportera de manière identique avec votre base MariaDB que MySQL. En cas de doute, vous pouvez vous en assurer en vérifiant la validité des comparaisons de dates (ex. >=) dans quelques-unes de vos requêtes SQL, du fait que MariaDB respecte plus strictement les types que MySQL.

Remerciez MySQL

La majorité des erreurs que vous pouvez rencontrer survient généralement lors de la migration d'une ancienne base MySQL vers MariaDB. La cause principale dans 98% des cas : MariaDB refuse des dates invalides que MySQL acceptait jusqu'alors (ex. 0000-00-00). MySQL a longtemps toléré ces données pourtant invalides au sens du standard SQL.

Votre application ASP Classic fonctionne bien avec votre base historique MySQL, puis vous la convertissez vers MariaDB. Et là tout explose ! Vous incriminez MariaDB et pestez contre ses bugs, mais en réalité, il n'en est rien : les solutions sont heureusement proches et faciles. La réponse efficace consiste à nettoyer vos données, clarifier le schéma, et parfois ajuster le code applicatif côté ASP Classic de manière minime.

MariaDB ne crée pas le problème, il l'expose. À ce titre, remerciez MySQL et ses pratiques permissives historiques. Là où vous avez cru qu'il vous rendait service, il ne faisait que vous donner sa bénédiction lorsque vous commetiez de très mauvaises actions avec vos données. Il aurait du vous avertir, mais il a préféré vous laisser stocker des dates incorrectes et inexistantes.

Les mauvaises pratiques héritées du passé expliquent la fréquence des bugs liés aux dates et heures lors de migrations, imports, exports, ou tout simplement lors de la consommation des données via des Drivers ODBC modernes et conformes aux standards.

Cette migration de données agit comme un révélateur des données historiquement incorrectes, en particulier sur les dates. La présence de ces données incorrectes vous alerte par voie de conséquence sur les points améliorables dans votre schema et/ou votre code ASP.

La gestion saine des dates et heures dans MySQL et MariaDB n'est pas une coquetterie, mais bien une garantie de fiabilité de votre application d'une part, et des données que vous prenez grand soin à stocker d'autre part.

Conseils et bonnes pratiques

Les conseils et bonnes pratiques suivants vous permettent de faire face aux situations potentiellement bloquantes les plus fréquemment rencontrées lorsque vous gérez des dates dans des bases MySQL/MariaDB, et que vous les exploitez depuis ASP Classic.

ASP Classic n'est ici aucunement fautif, pas plus que le Driver ODBC MySQL ou MariaDB : tous les problèmes évoqués relèvent pour leur immense majorité de la conception de la base de données en elle-même. Une fois votre schema corrigé et vos données historiques nettoyées, vous pouvez dormir tranquille 🛌.

Ce guide est complet et couvre une multitude de cas : il y a généralement peu de raison que vous ayez besoin de tout appliquer, et seules quelques-unes de ces astuces pourront généralement suffire à résoudre les petits bugs auxquels vous faites face.

Nous sommes rompus aux cas particuliers et à votre service pour vous assister avec votre code ASP Classic lors de vos migrations, améliorations, ou résolution de bugs difficiles.

Conseils lors de la conception du schema

Le point clef est : Rationalisez votre schema.

Le schema de votre base de données définit l'ensemble des règles qui seront applicables lors de son exploitation en lecture et en écriture. Plus ce schema est fourni et réfléchi, plus votre application est prévisible, et plus vos données sont fiables.

Vous pourrez contourner la quasi-totalité de ces problèmes de rigueur et passer outre : notre article vous en détaille les possibilités. Gardez néanmoins à l'esprit que, bien que cela soit techniquemnt fonctionnel, ces contournements n'ont vocaiton qu'à être temporaires, car le problème de fond subsiste : des dates/heures incorrectes existent en base, et résoudre le problème à la source est votre meilleure garantie. Vouloir simplement les contourner et les ignorer vous obligera dans le cas contraire à coder de très (trop) nombreuses vérifications en ASP Classic pour gérer les dates incorrectes, alors que la meilleure manière de vous défendre contre cet ennemi est de ... ne plus avoir à l'affronter du tout.

Conformer votre base de données n'est généralement pas une tâche longue. Une fois les dates nettoyées et le schéma clarifié, MariaDB s'avère bien plus prévisible que MySQL, ce qui permet à votre application ASP Classic de gagner en pérennité et surtout en stabilité. Et dans de nombreux cas, en performances également.

Stocker les dates dans DATETIME

Lorsque vous définissez la stucture de votre table, choisissez le type DATE ou DATETIME. Vous pouvez choisir TIMESTAMP si vous avez explicitement besoin d'une gestion automatique du fuseau horaire.

Ne stockez jamais de date dans un champ de type VARCHAR, au risque de ne pas pouvoir filtrer ou comparer sur ces champs de manière efficace d'une part, et de ralentir drastiquement les performances d'autre part.

Ne pas stocker de date dans VARCHAR

Stocker vos données de date/heure dans un champ de type VARCHAR est l'assurance de problèmes aujourd'hui ou demain. Cela vous empêche d'effectuer des comparaison et tris efficaces, ou vous oblige à recourir à la fonction STR_TO_DATE() de manière systématique dans vos requêtes de lecture, ce qui dégrade grandement les performances de vos requêtes.

Exemple de mauvaise pratique :

-- Lire depuis le champ "d_date_txt" de type VARCHAR.
-- Tenter de convertir la chaine en date selon le pattern indiqué :
----- Échouera à la première donnée qui ne respecte pas le pattern !
SELECT
   STR_TO_DATE(d_date_txt, '%Y-%m-%d %H:%i:%s') AS d_date_safe
FROM myTable;

Définir une valeur par défaut

NULL

La valeur NULL est la seule valeur par défaut que vous devez utiliser si aucune date n'existe. Elle est standard, fiable, et à l'épreuve du futur.

Pourquoi NULL est votre nouveau meilleur ami :

•  Elle est conforme au standard SQL
•  Elle représente la réelle absence de valeur
•  Elle est nativement supporté par MariaDB
•  Elle est compatible avec les modes SQL stricts (STRICT_TRANS_TABLES, NO_ZERO_DATE)

Exemple de bonne pratique :

-- Création de table
-- Utiliser une valeur NULL par défaut => Valide sous MySQL et MariaDB
CREATE TABLE contactRequests (
  d_dateReceived DATETIME NULL DEFAULT NULL
);

CURRENT_TIMESTAMP

Lorsqu'un champ est voué à toujours contenir la date d'ajout ou de dernière mise à jour, il est inutile de calculer et construire la date courante dans votre code ASP : déléguez cette tâche au moteur MySQL/MariaDB en définissnt la valeur par défaut de votre champ à CURRENT_TIMESTAMP. De cette manière, la date courante sera utilisée comme valeur au moment de l'insertion (INSERT INTO) ou de la mise à jour (UPDATE).

Exemples de définition dans votre schema :

-- Création de table
CREATE TABLE contactRequests (
   d_dateReceived DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- Altération d'une table existante
ALTER TABLE contactRequests MODIFY d_dateReceived DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;

Au moment d'écrire dans votre table, vous devrez soit fournir explicitement CURRENT_TIMESTAMP comme valeur pour ce champ, soit omettre complètement ce champ dans votre requête et ne pas fournir de valeur : le moteur s'en chargera implicitement. Ne spécifiez pas NULL, qui sera refusé.

Exemples au moment de l'écriture :

-- Ne pas spécifier le champ "d_dateReceived" :
-- il est automatiquement rempli avec la date courante.
INSERT INTO contactRequests (s_firstname, s_lastname)
VALUES ('John', 'Duff');

-- Fournir explicitement CURRENT_TIMESTAMP
-- (redondant et inutile, mais fonctionnel)
INSERT INTO contactRequests (s_firstname, s_lastname, d_dateReceived)
VALUES ('John', 'Duff', CURRENT_TIMESTAMP);

-- Fournir explicitement NULL
-- => PROVOQUE UNE ERREUR !
INSERT INTO contactRequests (s_firstname, s_lastname, d_dateReceived)
VALUES ('John', 'Duff', NULL);

0000-00-00 00:00:00

Il vous est techniquement possible d'utiliser '0000-00-00 00:00:00' comme date par défaut. Du moins c'est ce que MySQL vous a laissé croire jusqu'à ce jour. Mais ne le faites pas (sinon cessez de lire cet article). Les diverses conséquences négatives que cela implique doivent vous faire privilégier NULLà tout point de vue.

Quelques informations sur votre ennemi '0000-00-00 00:00:00' sont nécessaires pour vous convaincre :

•  C'est une spécificité de MySQL héritée pour permettre une compatibilité historique.
•  Ce n'est pas une date correcte : elle n'existe pas dans le calendrier.
•  C'est problématique pour échanger vos données avec d'autres API, connecteurs, ORM, ou exports.
•  Cela ne renseigne pas sur l'état réel de la donnée : non reçue ? inconnue ? erreur ? valeur par défaut ? valeur historique ? Si vous avez réellement besoin d'un état explicite « non encore reçu », ajoutez une colonne de statut, au lieu de détourner le champ date.
•  Cela perturbe les comparaisons et tris.
•  Cela renvoie des erreurs dans des sql_mode "stricts" (ex. NO_ZERO_DATE, NO_ZERO_IN_DATE).
•  '0000-00-00 00:00:00' est une valeur à éviter sauf contrainte absolue. Vous devrez alors dans ce cas "ruser" pour contourner ces données invalides, et être en mesure de les utiliser depuis votre code ASP. L'usage de Flags OPTION sera alors requis.

Exemple de mauvaise pratique :

-- Création de table
-- Utiliser une Date invalide par défaut => historiquement tolérée par MySQL
CREATE TABLE contactRequests (
   d_dateReceived DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00'
);

Rendre la date obligatoire

Vous pouvez rendre un champ date obligatoire, afin d'interdire toute valeur vide, NULL ou par défaut, y-compris CURRENT_TIMESTAMP. Vous devez pour cela ne définir aucune valeur par défaut pour ce champ, et interdire NULL.

Votre objectif réel est donc : « La date doit venir de l'application ASP, pas du schéma ».

Exemples de definition dans votre schema :

-- Créer la table
---- d_dateReceived est obligatoire
---- NULL est interdit
---- aucune valeur par défaut n'est fournie
---- toute requête INSERT/UPDATE doit explicitement fournir d_dateReceived, sinon elle échoue
CREATE TABLE contactRequests (
  d_dateReceived DATETIME NOT NULL
);

-- Modifier la table existante
-- Échouera si une seule ligne contient encore NULL dans d_dateReceived => Nettoyer la table avant.
---- d_dateReceived est obligatoire
---- NULL est interdit
---- aucune valeur par défaut n'est fournie
---- toute requête INSERT/UPDATE doit explicitement fournir d_dateReceived, sinon elle échoue
ALTER TABLE contactRequests
MODIFY d_dateReceived DATETIME NOT NULL;

À partir de ce moment :

•  Toute insertion sans spécifier de valeur pour la colonne provoque une erreur
•  Toute insertion avec NULL provoque une erreur
•  Aucune valeur automatique CURRENT_TIMESTAMP n'est appliquée par défaut

Exemples lors de l'écriture :

-- Exemple avec aucune valeur fournie :
-- La requête provoque un échec.
INSERT INTO contactRequests (s_firstname, s_lastname)

-- Exemple avec une valeur valide :
-- La requête est acceptée.
INSERT INTO contactRequests (s_firstname, s_lastname, d_dateReceived)
VALUES ('John', 'Duff', '2026-09-01 14:35:12');

-- Exemple de requête avec CURRENT_TIMESTAMP :
-- CURRENT_TIMESTAMP est utilisé ici comme valeur explicite, et non par défaut.
-- La requête est acceptée.
INSERT INTO contactRequests (s_firstname, s_lastname, d_dateReceived)
VALUES ('John', 'Duff', CURRENT_TIMESTAMP);

En plus de rendre votre champ obligaoire, vous pouvez souhaiter contraindre la valeur qui sera acceptée par votre champ. Faites alors usage de l'instruction SQL CHECK : une contrainte automatique sera appliquée à chaque INSERT et UPDATE. Retenez à ce sujet que la contrainte CHECK est effectivement appliquée par MariaDB, contrairement aux anciennes versions de MySQL. L'application de cette contrainte suppose donc d'une part que vous exécutiez votre requête de création/altération de table avec un sql_mode strict pour éviter les insertions silencieusement corrigées, et que vous ayez déjà nettoyé les dates invalides de votre table d'autre part. D'une manière générale, nettoyez toujours vos donnez avant de modifier votre schema, car ce dernier s'applique immédiatement aux données déjà existantes.

Exemples de definition dans votre schema :

-- Créer la table
---- d_dateReceived est obligatoire
---- NULL est interdit
---- aucune valeur par défaut n'est fournie
---- toute requête INSERT/UPDATE doit explicitement fournir d_dateReceived, sinon elle échoue
---- Contrainte supplémentaire : Interdit les dates antérieures à 2012
CREATE TABLE contactRequests (
   d_dateReceived DATETIME NOT NULL,
   CONSTRAINT chk_dateReceived
      CHECK (d_dateReceived >= '2012-01-01')
);

-- Modifier la table existante
-- Échouera si une seule ligne contient encore NULL dans d_dateReceived => Nettoyer la table avant.
---- d_dateReceived est obligatoire
---- NULL est interdit
---- aucune valeur par défaut n'est fournie
---- toute requête INSERT/UPDATE doit explicitement fournir d_dateReceived, sinon elle échoue
---- Contrainte supplémentaire : Interdit les dates antérieures à 2012
ALTER TABLE contactRequests
ADD CONSTRAINT chk_dateReceived
CHECK (d_dateReceived >= '2012-01-01');

Conseils lors de l'importation de données

Importer votre base MySQL dans MariaDB est en général transparent. Toutefois, si vous rencontrez une erreur sur un champ de type DATE, DATETIME ou TIMESTAMP, c'est que le moteur de MariaDB rencontre des dates incorrectes.

Une date invalide ne peut exister dans une colonne DATE/DATETIME si sql_mode est strict. Certaines techniques de contournement (ex. ajustement temporaire du sql_mode) sont présentées ici pour vous permettre de forcer MariaDB à importer vos données "sales" sans recevoir aucune plainte de sa part.

Par la suite, une fois vos données importées, vous pouvez alors les nettoyer, puis finir en ajustant votre schema pour garantir la santé des données futures.

Importer grâce au sql_mode

Le moteur MySQL/MariaDB permet d'appliquer différents niveaux de rigueur. Le mode SQL sql_mode est prévu à cet effet. Il peut être tentant d'ajouter des exceptions au sql_mode lors de la connexion ODBC afin d'utiliser voire d'abuser de ce mode pour "faire avec" des données incorrectes lors de la lecture, ou "être laxiste" lors de l'écriture, mais c'est une très mauvaise idée.

Ce mode SQL doit être utilisé comme contournement temporaire lors d'une session d'import, avant de finalement nettoyer les données puis rationaliser votre schema. Ce mode SQL ne doit plus être utilisé en production lors de la lecture/écriture via l'attribut INITSTMT de votre chaîne de connexion, sauf absolue nécessité.

Le mode SQL peut être spécifié de différentes manières, avec une portée différente :

•  Définition permanente (fichier de configuration my.ini) :
  Il vous garantit une contrainte systémique en production.
  INI

  [mysqld]
  sql_mode=STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE

  
  
•  Définition lors de l'import :
  Il s'applique à la connexion courante. Utilisez-le lors de l'importation de vos données depuis phpMyAdmin, Navicat, HeidiSQL, etc.
  SQL

  SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE';

  
  
•  Définition dans votre connexion ODBC :
  Vous pouvez définir le mode SQL au sein de l'attribut INITSTMT de votre chaîne de connexion : cet attribut permet au Driver ODBC d'exécuter une instruction SQL à l'ouverture de la connexion.
  ASP CLASSIC

  <%
  'Déclarer la chaine de connexion à la base via le Driver MariaDB
  '(avec un sql_mode personnalisé)
  Dim dbConnString : dbConnString = "Driver={MariaDB ODBC 3.2 Driver}; Server=127.0.0.1; Charset=utf8; Port=3306; Database=dbName_abcdef; User=dbUser_test_abc123; Password=dbPw_abcdef12345; InitStmt={SET SESSION sql_mode='STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE';}"
  %>

  
  Le SET SESSION sql_mode est exécuté lors de chaque connexion, et n'est garanti que pour cette connexion uniquement. Le plus grand risque est qu'un pool de connexions peut réutiliser une session avec un autre sql_mode. De plus, lors d'une requête SQL ultérieure dans votre code, un SET sql_mode ultérieur peut l'écraser.

Retenez une fois encore qu'ajuster le mode SQL au niveau le plus haut, à savoir dans votre code applicatif ASP lors de votre connexion ODBC est déconseillé, et n'a pas forcément la portée suffisante. Ce sql_mode est plutôt destiné à être adapté de manière temporaire lors de vos importations de données, donc dans les requêtes que vous exécutez depuis phpMyAdmin ou depuis votre logiciel de gestion client (ex. HeidiSQL , Navicat, etc.). Une fois vos données importées (y-compris les dates historiquement incorrectes), nettoyez-les.

À l'issue de vos usages du mode SQL à des fins de contournement lors de vos migrations, le mode strict doit être privilégé de manière globale et permanente, et défini au niveau le plus bas, à savoir dans le fichier de configuration my.ini à la section [mysqld].

Nettoyer après import

 AVERTISSEMENT : Le nettoyage de votre base de données implique des modifications du schema, des remplacements de données, et des suppressions d'enregistrements. Assurez-vous avant toute opération de réaliser des sauvegardes/backups/DUMP de vos bases de données. Il est également conseillé d'en réaliser à chacune des étapes importantes de vos opérations de nettoyage. Vous pourrez ainsi faire marche arrière en cas d'erreur, sans perdre vos optimisations précédentes.

Notez que les requêtes SELECT et UPDATE présentées ci-après dans cette section ne fonctionneront que si sql_mode n'interdit pas déjà les dates zéro au moment de l'exécution, sinon l'opération échouera.

Après avoir importé vos données depuis MySQL, assurez-vous de les nettoyer.

Rechercher les dates invalides (dates à Zéro)

-- Le champ d_dateReceived est de type Date
-- Le seuil 1000-01-01 couvre les dates techniquement stockables,
-- mais invalides au sens du standard SQL.
SELECT *
FROM contactRequests
WHERE d_dateReceived = '0000-00-00 00:00:00'
   OR d_dateReceived < '1000-01-01';

Il vous appartient à ce moment de décider ce que vous souhaitez faire avec ces données incorrectes :

• soit supprimer les lignes concernées
• soit les remplacer par une vraie date métier (ex. date de création, date de commande, etc.)
• soit les remplacer par NULL

Remplacer les dates incorrectes par NULL (dates à Zéro)

UPDATE contactRequests
SET d_dateReceived = NULL
WHERE d_dateReceived = '0000-00-00 00:00:00'
   OR d_dateReceived < '1000-01-01';

Modifier le schema (dates à Zéro)

Vous devez désormais forcer la valeur par défaut à NULL (ou CURRENT_TIMESTAMP).

D'une manière générale, nettoyez toujours vos données avant de modifier votre schema, car ce dernier s'applique aux données déjà existantes.

Conseils lors de l'écriture de données

Fournir à MySQL/MariaDB des dates propres et valides est l'assurance de ne pas avoir à traiter de date invalide à l'avenir. Les conseils suivants vous permettent de vous assurer que votre code ASP Classic envoie systématiquement une valeur valide au moteur SQL.

Ne pas fournir de valeur vide

Dans votre code ASP Classic, assurez-vous de ne jamais envoyer de chaîne vide à un champ de type DATE ou DATETIME, mais toujours à-minima la chaîne "NULL", seule valeur acceptable comme valeur par défaut si le schema de votre table spécifie NULL pour ce champ. Si vous utilisez une requête paramétrée ADODB.Command, spécifiez adDate ou adDBTimeStamp comme type de variable, ou fournissez-lui le type variant VBScript Null.

Si vous souhaitez que la date courante soit stockée, définissez alors CURRENT_TIMESTAMP comme valeur par défaut dans le schema de votre table pour ce champ. La valeur NULL sera désormais refusée.

<%
'Spécifier NULL via une requête SQL classique
'-	-	-	-	-	-	-	-	-	-	-	-
strSQL = "INSERT INTO contactRequests (d_dateReceived) VALUES (NULL)"
dbConn.Execute(strSQL)


'Spécifier NULL via une requête SQL paramétrée
'-	-	-	-	-	-	-	-	-	-	-	-
'N'utilisez pas vbNull : c'est une constante de type (masque interne VBScript)
Set paramCmd = Server.CreateObject("ADODB.Command")
Set paramCmd.ActiveConnection = dbConn
paramCmd.CommandText = "INSERT INTO contactRequests (d_dateReceived) VALUES (?)"
paramCmd.Parameters.Append paramCmd.CreateParameter("@d_dateReceived", adDBTimeStamp, adParamInput, , Null)
paramCmd.Execute
%>

Fournir une date au format ISO

La manière la plus sûre de fournir une date lors de votre requête à MySQL/MariaDB est de lui fournir une variable ASP/VBscript de type Date, puis de l'injecter dans votre requête au moyen d'une requête paramétrée via ADODB.Command en forçant explicitement le type ADO à adDate ou adDBTimeStamp. Le type de donnée est ainsi explicite, et vous n'avez aucune conversion ou formatage de la date/heure à effectuer côté ASP. Les requêtes paramétrées vous prémunissent également contre les risques d'injection SQL.

Si vous ne pouvez pas utiliser de requête paramétrée, construisez la chaîne de date qui sera fournie à MySQL/MariaDB au format ISOYYYY-MM-DD HH:MM:SS, en utilisant le code suivant :

<%
'Renvoyer une date formatée pour MySQL/MariaDB au format "YYYY-MM-DD HH:MM:SS"
Function DateFormat_MySQL_MariaDB(byVal dtInput)

   'Paramètre  Variable   Type          Description
   '---------  --------   ----          -----------
   '@param     dtInput    String/Date   Date ou Date/Heure (type VBScript/ASP "String" ou "Date")
   '@return    dtOutput   String/Null   Chaine de date formatée "YYYY-MM-DD HH:MM:SS", ou bien Null.

   Dim sYear, sMonth, sDay, sHour, sMinute, sSecond
   Dim dtOutput : dtOutput = Null
   
   'Si l'entrée est convertible en type "Date"
   If (IsDate(dtInput)) Then
      'Récupérer les parties de la date
      sYear   = CStr(Year(dtInput))
      sMonth  = Right("0" & Month(dtInput), 2)
      sDay    = Right("0" & Day(dtInput), 2)
      
      'Vérifier si une heure est présente
      If ((Hour(dtInput) + Minute(dtInput) + Second(dtInput)) > 0) Then
         sHour   = Right("0" & Hour(dtInput), 2)
         sMinute = Right("0" & Minute(dtInput), 2)
         sSecond = Right("0" & Second(dtInput), 2)
      Else
         sHour   = "00"
         sMinute = "00"
         sSecond = "00"
      End If
      
      'Construire la chaine de date au format ISO pour MySQL/MariaDB
      dtOutput = sYear & "-" & sMonth & "-" & sDay & " " & sHour & ":" & sMinute & ":" & sSecond
   Else
      dtOutput = Null 'Renvoyer Null si l'entrée n'est pas une date valide
   End If

   'Return
   DateFormat_MySQL_MariaDB = dtOutput

End Function 'DateFormat_MySQL_MariaDB



'= =  =  =  =  =  =
'Exemples d'utilisation
'= =  =  =  =  =  =

Dim dateSource, datetimeSource, dateStringForSQL

'Ex. Gestion d'une date en Anglais
'---------------------------------
SetLocale(1033) 'Régler LCID en Anglais

'Définir/lire une date source (au format Anglais) - de type vbString.
dateSource = "04/13/2026" 'ex. 13 Avril

'Renvoyer la date formatée pour MySQL/MariaDB
'=> RENVOIE : 2026-04-13 00:00:00
dateStringForSQL = DateFormat_MySQL_MariaDB(dateSource)


'Ex. Gestion d'une date en Français
'----------------------------------
SetLocale(1036) 'Régler LCID en Français

'Définir/lire une datetime source (au format Français) - de type vbDate.
datetimeSource = #01/09/2026 14:35:12# 'ex. 1 septembre

'Renvoyer la date formatée pour MySQL/MariaDB
'=> RENVOIE : 2026-09-01 14:35:12
dateStringForSQL = DateFormat_MySQL_MariaDB(datetimeSource)


'Définir la requête d'insertion dans la base de données
'Utiliser la date déjà correctement formatée pour MySQL/MariaDB
strSQL = _
   "INSERT INTO contactRequests ( " & _
      "s_firstname, " & _
      "s_lastname, " & _
      "d_dateReceived " & _
   ") VALUES ( " & _
      "'John', " & _
      "'Duff', " & _
      "STR_TO_DATE('" & dateStringForSQL & "') " & _
   ") "

'Ajouter dans la base de données
dbConn.Execute(strSQL)
%>

Fournir une date au format personnalisé

Lorsque vous disposez d'une variable ASP/VBScript qui n'est ni de type vbDate, ni une chaîne vbString contenant une date au format ISO compréhensible par MySQL/MariaDB, vous devez alors fournir au moteur de base de données des indications sur le format (pattern) de votre date, afin qu'il la "parse" selon ce pattern. Vous pouvez utiliser différents marqueurs dans votre pattern (ex. %Y %m %d %H %i %s etc.).

Cette technique permet à MySQL/MariaDB de savoir traduire votre chaîne de caractères en date réelle qu'il sera en mesure de stocker. Utilisez pour cela la fonction SQL native suivante : STR_TO_DATE().

<%
'Définir un datetime avec un format Arbitraire/Exotique - de type vbString.
Dim datetimeSource : datetimeSource = "Annee=2026 Mois=09 Heure=14 Seconde=12 Jour=01 Minute=35"

'Définir un masque/pattern permattant à MySQL/MariaDB de comprendre la chaine fournie
'(contient les marqueurs %Y %m %d %H %i %s, qui sont reconnus MySQL/MariaDB)
Dim datetimeMask : datetimeMask = "Annee=%Y Mois=%m Heure=%H Seconde=%s Jour=%d Minute=%i"

'Définir la requête d'insertion dans la base de données
strSQL = _
   "INSERT INTO contactRequests (" & _
      "s_firstname, " & _
      "s_lastname, " & _
      "d_dateReceived " & _
   ") VALUES (" & _
      "'John', " & _
      "'Duff', " & _
      "STR_TO_DATE('" & datetimeSource & "', '" & datetimeMask & "') " & _
   ")"

'Ajouter dans la base de données
dbConn.Execute(strSQL)
%>

Notez toutefois que vous dépendez ici d'un format figé : la moindre variation dans la chaîne fera échouer votre requête, du fait que STR_TO_DATE() ne le comprendra pas. Cette technique vous expose fortement aux injections SQL si datetimeSource ou d'autres valeurs deviennent dynamiques. Préférez toujours les requêtes paramétrées. Prenez contact avec nous si vous avez besoin d'implémenter des requêtes paramétrées de manière efficace dans votre code source ASP, nous en maîtrisons toutes les subtilités pour les implémenter au mieux.

Laisser le moteur SQL utiliser la date courante

Si vous devez stocker la date courante au moment de l'insertion (INSERT INTO) ou de la mise à jour (UPDATE), appuyez-vous sur la valeur par défaut de votre champ. Cela vous évitez d'avoir à construire la date dans votre code ASP : vous déléguez cette tâche au moteur MySQL/MariaDB.

Consultez cette section pour mettre en œuvre cette technique.

Conseils lors de la lecture de données

Lire les dates depuis une base MySQL/MariaDB semble être une opération simple. Toutefois, selon que votre base contient éventuellement des dates historiquement incorrectes, ou que vous souhaitez les lire selon un format particulier, certaines précautions et techniques sont à considérer.

Utiliser des requêtes paramétrées

Toute création de requête SQL depuis votre code ASP comporte un risque important d'injection SQL si vous concaténez des chaînes, variables et données, en particulier si certaines de ces données ont été saisies par un utilisateur et ne sont pas sous votre contrôle.

Pour vous prémunir contre les injections SQL, utilisez plutôt des requêtes paramétrées via ADODB.Command, en spécifiant chaque paramètre sous forme de ?. Pensez à forcer le type ADO en adDate ou adDBTimeStamp au lieu de laisser ADO deviner : cela limite les conversions implicites et les erreurs silencieuses.

Gérer les valeurs sales

Si vous avez un doute sur la propreté du schema de la table ou des données qu'elle contient, ajoutez des sécurités dans vos requêtes SQL pour éviter de buter sur des données sales et incorrectes, ou de les renvoyer à votre application ASP. Notez que ces pratiques vous permettent de contourner une date invalide, mais ralentissent l'exécution de vos requêtes. Nettoyer vos données à la source reste la meilleure pratique.

Ces requêtes vous permettent donc de "faire avec" des données historiquement incorrectes, mais ont un coût en raison du filtrage qu'elles effectuent. Elles constituent de par le fait un "pansement", si vous n'avez aucun autre choix que de devoir traiter des données historiquement sales et incorrectes, et que vous n'avez pas encore effectué de nettoyage.

-- VARIANTE 1 : Plus concise
-- Les performances sont équivalentes entre CASE et NULLIF y compris sur de grands volumes.
-- CAST() n'a aucun impact en termes de performances.
-- *  *  *  *  *
-- Lire depuis le champ "d_date" de type DATETIME
-- S'assurer qu'une donnée est bien une date valide
-- Renvoie NULL sinon
SELECT
   CAST(
      NULLIF(
         IF(d_date < '1000-01-01', NULL, d_date),
         '0000-00-00 00:00:00'
      )
   AS DATETIME) AS d_date_safe
FROM contactRequests

-- VARIANTE 2 : Plus lisible
-- Les performances sont équivalentes entre CASE et NULLIF y compris sur de grands volumes.
-- CAST() n'a aucun impact en termes de performances.
-- *  *  *  *  *
-- Lire depuis le champ "d_date" de type DATETIME
-- S'assurer qu'une donnée est bien une date valide
-- Renvoie NULL sinon
SELECT
   CAST(
      CASE
         WHEN d_date = '0000-00-00 00:00:00' THEN NULL
         WHEN d_date < '1000-01-01'          THEN NULL
         ELSE d_date
      END
   AS DATETIME) AS d_date_safe
FROM contactRequests

Le cas le plus délicat est celui des dates et heures stockées dans un champ de type VARCHAR. Le code suivant vous montre comment gérer ce type de cas dans une clause SELECT, mais retenez que filtrer ou comparer sur ces champs dans une clause WHERE est quasiment impossible, et risque de ralentir drastiquement les performances d'autre part.

-- Lire depuis le champ "d_date_txt" de type VARCHAR
-- Tenter de convertir la chaine en date selon le pattern indiqué
----- Échouera à la première donnée qui ne respecte pas le pattern !
SELECT
   STR_TO_DATE(d_date_txt, '%Y-%m-%d %H:%i:%s') AS d_date_safe
FROM myTable;

Enfin, si vos données sont propres et que votre schema spécifie NULL comme valeur par défaut, alors toutes vos lignes sont saines. Votre requête peut alors être aussi simple et courte que cela :

SELECT d_date FROM myTable WHERE d_date IS NOT NULL

Lire une date au format personnalisé

Lorsque vous souhaitez lire une date selon un format particulier, exotique ou localisé, vous pouvez faire appel à la fonction DATE_FORMAT() de MySQL/MariaDB, comme suit :

<%
'On souhaite récupérer la date au format Exotique suivant : YYYY/MM hh:ss
'   L'usage de cette fonction DATE_FORMAT() ralentit votre requête.
'   De ce fait il sera plus efficace de lire la donnée brute depuis MySQL/MariaDB,
'   puis d'utiliser ASP/VBScript pour en extraire les parties et la formater.
Dim dateMask : dateMask = "%Y/%m %H:%i"

'Définir la requête de lecture
Dim strSQL : strSQL = "SELECT DATE_FORMAT(contactRequests.d_dateReceived, '" & dateMask & "') AS myDate FROM contactRequests "

'Ouvrir la connection
Set dbConn = Server.CreateObject("ADODB.Connection")
dbConn.Open dbConnString

'Ouvrir le Recordset en mode "Forward-Only" via .Execute()
Set rs = dbConn.Execute(strSQL)
%>

Contourner les dates à Zéro

Premièrement, ce conseil est temporaire. Il vous est possible de désactiver temporairement les contrôles stricts côté driver via le paramètre OPTION dans votre chaîne de connexion, mais notez que ce n'est PAS une solution à long terme : seulement un contournement autour de vos données invalides.

Contourner (ignorer) les données invalides lors de la lecture est un pansement. L'approche que vous devez suivre est la suivante :

• Après l'import : Corriger vos données vers NULL, puis ajuster votre schema en définissant NULL comme valeur par défaut,
• Lors de l'écriture : Normaliser les données que vous fournissez à votre requête SQL.

Lors d'une migration de données depuis MySQL vers MariaDB, MariaDB est plus strict et refuse l'importation de votre table si elle contient des dates vides 0000-00-00 00:00:00. Toutefois, si vous avez forcé leur importation mais que vous avez oublié de les nettoyer, alors ces données incorrectes s'y trouvent encore.

Lorsque votre table contient des enregistrements avec des dates invalides (ex. 0000-00-00 00:00:00), ADO est susceptible de vous faire suivre un message d'erreur provenant du moteur MySQL/MariaDB, pour se plaindre de la présence de telles dates vides. Notre meilleur conseil est à ce stade de nettoyer vos données.

Toutefois, si vous souhaitez réellement permettre à votre application ASP d'accéder à ces données, vous pouvez alors utiliser les valeurs de certains Flags dans le paramètre OPTION de votre chaîne de connexion afin de pouvoir lire depuis cette table sans rencontrer d'erreur côté ASP. Cela revient en pratique à demander au Driver ODBC de se comporter comme MySQL le faisait historiquement, même si MariaDB est plus strict.

Ces options doivent être utilisées temporairement pour assurer la compatibilité de votre application ASP Classic avec une base de données contenant des dates invalides héritées de MySQL, mais elles ne doivent pas être considérées comme une solution définitive.

Références pour le paramètre OPTION :

• Référence & Liste complète MySQL :
  • https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-configuration-connection-parameters.html#codbc-dsn-option-flags 
• Références & Listes incomplètes MariaDB (certains paramètres de MySQL peuvent encore être pris en charge, sans garantie) :
  • https://mariadb.com/docs/connectors/mariadb-connector-odbc/mariadb-connector-odbc-guide#general-connection-parameters 
  • https://docs.skysql.com/Connecting%20to%20SkySQL%20DBs/Connect%20using%20ODBC/#options-bitmask 

•  Flags concernés
  • 16777216 : Autorise les dates invalides (ex. 0000-00-00, 0000-00-00 00:00:00) sans erreur côté driver.
  • 33554432 : Désactive certains contrôles stricts supplémentaires sur les conversions de dates et d'horodatages.
•  Utilisation recommandée
  • Utilisez ces Flags de manière temporaire, puis :
    1. Nettoyez les dates invalides dans votre base,
    2. Adaptez le schéma de votre table (ex. DATETIME NULL),
    3. Affranchissez-vous progressivement du paramètre OPTION.
•  Quand les utiliser
  • Migration urgente sans possibilité immédiate de nettoyer vos données
  • Phase de diagnostic ou d'audit technique
  • Code source figé difficile à modifier
•  Quand ne PAS les utiliser
  • Lors d'un nouveau développement
  • Après la phase de migration des données
  • Comme solution définitive, sinon vous institutionnalisez une dette technique sur votre application
•  Limitations importantes
  • Ces options ne corrigent pas les données
  • Elles masquent des incohérences fonctionnelles
  • Elles rendent le comportement dépendant du Driver ODBC
  • Elles réduisent la portabilité de la base et la fiabilité de vos données
•  Effets immédiats (mais temporaires)
  • L'import ou l'exécution de code ASP Classic existant ne génère plus d'erreur
  • Les anciennes bases sont acceptées par MariaDB sans modification immédiate des données

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