Erreurs de requête SQL SFMC : causes courantes et solutions

Votre requête passait sans souci dans SQL Server Management Studio, puis Automation Studio l'a refusée. Les erreurs de requête SQL SFMC n'ont presque jamais de cause mystérieuse : elles viennent d'une courte liste de situations, chacune avec une correction rapide.

La réponse directe : SFMC exécute une version restreinte de SQL Server, limitée aux instructions SELECT. La plupart des échecs viennent d'une syntaxe non prise en charge (variables, tables temporaires, CTE), de noms d'objets ou de colonnes qui ne correspondent pas exactement, d'une data extension cible incompatible avec le résultat, ou d'une requête qui dépasse la limite de 30 minutes.

‍

Ce guide passe en revue chaque famille d'erreurs, propose deux requêtes qui fonctionnent pour les cas les plus souvent mal gérés, et se termine par une check-list à copier.

‍

Pourquoi une requête SQL SFMC échoue

‍

SFMC n'accepte qu'un dialecte SQL restreint

Une activité de requête n'accepte que des instructions SELECT, sur des data extensions ou des data views de votre compte ou de son compte parent. Les jointures, UNION, GROUP BY, les requêtes imbriquées, CASE et la plupart des fonctions fonctionnent. Beaucoup d'habitudes prises ailleurs avec SQL Server, non.

La référence SQL officielle de Marketing Cloud Engagement (en anglais) détaille ce qui est pris en charge. Gardez-la ouverte pendant vos tests.

‍

Trois moments où l'erreur peut apparaître

Certaines erreurs surviennent à l'enregistrement ou à la validation, d'autres à l'exécution, et d'autres encore seulement quand SFMC écrit les lignes dans la data extension cible. Identifier le moment de l'échec indique où chercher.

• Erreurs de syntaxe ou d'objet : le texte de la requête est faux, ou pointe vers un élément qui n'existe pas.
• Erreurs de cible : la requête est valide, mais son résultat ne rentre pas dans la data extension de destination.
• Erreurs d'exécution : la requête est valide et compatible, mais elle dure trop longtemps ou rencontre des données inattendues.

‍

Erreurs de syntaxe : ce que le SQL de SFMC ne prend pas en charge

‍

Variables, tables temporaires et CTE

Ce sont les réflexes les plus courants venus d'autres projets SQL. SFMC ne gère ni les variables, ni les curseurs, ni les fonctions définies par l'utilisateur, ni les tables temporaires, ni les expressions de table commune (CTE). Une requête qui commence par DECLARE ou WITH échouera.

La solution passe presque toujours par une sous-requête. Tout ce que vous mettriez dans une CTE peut se placer dans la clause FROM sous forme de table dérivée, comme dans l'exemple ci-dessous.

/* Latest row per subscriber, no CTE and no temp table */
SELECT
  x.SubscriberKey,
  x.EmailAddress,
  x.ModifiedDate
FROM (
  SELECT
    SubscriberKey,
    EmailAddress,
    ModifiedDate,
    ROW_NUMBER() OVER (
      PARTITION BY SubscriberKey
      ORDER BY ModifiedDate DESC
    ) AS rn
  FROM Customers_Master
) x
WHERE x.rn = 1

Rôle de chaque partie :

• La sous-requête numérote les lignes de chaque SubscriberKey, de la plus récente à la plus ancienne selon ModifiedDate.
• ROW_NUMBER() avec PARTITION BY repart de 1 pour chaque abonné.
• La requête externe ne garde que la ligne numéro 1 : vous obtenez la dernière ligne de chaque abonné.
• Data extension cible : Latest_Subscriber_Rows. Clé primaire : SubscriberKey. Type de mise à jour : Overwrite.

Si vous hésitez sur l'action de données à choisir, lisez d'abord Overwrite, Update ou Append dans une requête SFMC.

‍

Commentaires et SELECT * avec une jointure

Les commentaires ouverts avec -- ne sont pas pris en charge : utilisez des blocs /* ... */. De plus, SELECT * est refusé dès qu'il y a un JOIN : nommez chaque colonne souhaitée.

Nommer les colonnes reste de toute façon une bonne pratique, car cela évite les collisions entre deux tables qui partagent un nom de champ.

‍

Erreurs d'objet et de colonne : des noms qui ne correspondent pas

‍

Invalid object name

Ce message signifie que SFMC ne trouve pas la table citée dans FROM ou JOIN. Les causes habituelles : une faute de frappe, une data extension située dans une autre business unit, ou une data view écrite sans son underscore initial, par exemple Sent au lieu de _Sent.

Pour une data extension partagée depuis une business unit parente, vérifiez si le préfixe ENT. est nécessaire. Copiez toujours la clé externe ou le nom depuis Contact Builder plutôt que de les saisir de mémoire.

‍

Invalid column name

Les noms de champs ne sont pas sensibles à la casse, mais l'orthographe doit être exacte. Piège fréquent : une colonne qui existe dans la data view mais pas dans votre data extension, ou l'inverse. Ouvrez la data extension et comparez la liste des champs avant de deviner.

Pour les tables d'engagement, la liste des colonnes dans interroger les data views SFMC en SQL est plus rapide à consulter que l'interface.

‍

Erreurs de data extension cible : la requête est valide, mais l'écriture échoue

‍

Noms de champs et types de données

Chaque colonne renvoyée par votre requête doit avoir un champ correspondant dans la data extension cible, avec un type compatible et une longueur suffisante. Un texte plus long que le champ cible, ou une date écrite dans un champ numérique, peut faire échouer l'activité alors que le SQL est correct.

Autre point : la sortie d'un champ décimal d'une data extension n'est pas renvoyée en décimal. Convertissez-la explicitement avec CAST si la cible attend un décimal.

‍

Doublons sur la clé primaire

Si la cible a une clé primaire et que votre requête renvoie deux lignes avec la même clé, l'écriture peut échouer. Agrégez ou dédoublonnez dans la requête pour que la clé soit unique. Gardez aussi la clé primaire sous 1 700 octets.

La requête suivante est un modèle sûr : une ligne par abonné, avec la date d'envoi la plus récente.

/* Subscribers sent an email in the last 30 days */
SELECT
  c.SubscriberKey,
  c.EmailAddress,
  MAX(s.EventDate) AS LastSendDate
FROM Customers_Master c
INNER JOIN _Sent s
  ON s.SubscriberKey = c.SubscriberKey
WHERE s.EventDate >= DATEADD(day, -30, GETDATE())
GROUP BY c.SubscriberKey, c.EmailAddress

Ligne par ligne :

• Le commentaire /* */ documente l'intention sans recourir au double tiret, non pris en charge.
• Les colonnes sont nommées explicitement : aucun SELECT * dans la requête.
• MAX(s.EventDate) conserve une seule date par abonné, ce qui protège la clé primaire.
• La clause WHERE limite l'analyse aux 30 derniers jours avec DATEADD et GETDATE, ce qui réduit aussi le temps d'exécution.
• GROUP BY énumère chaque colonne non agrégée.
• Data extension cible : Recent_Sends, avec SubscriberKey comme clé primaire. Type de mise à jour : Overwrite.

Pour d'autres calculs de dates, consultez les fonctions de date du SQL SFMC.

‍

Réponse rapide : check-list des erreurs SQL SFMC

‍

Utilisez ce tableau quand une requête échoue et que vous cherchez la cause rapidement.

‍

Échecs à l'exécution : timeouts et données inattendues

‍

La limite de 30 minutes

Une requête expire au bout de 30 minutes. Le remède consiste à lire moins de données : filtrer tôt sur une période, ne sélectionner que les colonnes utiles, et éviter de joindre de grosses tables sans condition sélective. Des index sur les data extensions jointes peuvent aussi aider.

Nous détaillons ce point dans timeout d'une requête SQL SFMC : causes et solutions.

‍

Tester avec TOP avant l'exécution complète

Pendant la mise au point, ajoutez TOP 100 et dirigez le résultat vers une data extension de test. Vous obtenez un retour rapide, sans écraser une audience de production avec un résultat à moitié correct.

Retirez le TOP une fois le résultat validé.

‍

Questions fréquentes

‍

Peut-on utiliser une CTE ou une table temporaire dans le SQL de SFMC ?

Non. Les tables temporaires et les expressions de table commune ne sont pas prises en charge. Remplacez-les par une sous-requête dans la clause FROM, ou scindez la logique en deux activités de requête qui écrivent dans une data extension intermédiaire.

‍

Pourquoi SELECT * échoue-t-il quand je joins des tables ?

SFMC n'autorise pas SELECT * avec un JOIN. Listez les colonnes nécessaires et ajoutez un alias à celles qui portent le même nom dans plusieurs tables.

‍

Pourquoi ma requête est-elle validée mais échoue-t-elle quand même ?

La validation contrôle la requête, pas la cible. L'exécution peut encore échouer si la data extension cible n'a pas un champ, si le type de données est incorrect, ou si des clés primaires sont en double.

‍

Combien de temps une requête SFMC peut-elle s'exécuter ?

Une activité de requête expire après 30 minutes. Réduisez la période, sélectionnez moins de colonnes et testez avec TOP pour rester bien en dessous de la limite.

‍

Peut-on écrire des commentaires dans le SQL de SFMC ?

Oui, mais avec des blocs /* */. Les commentaires ouverts avec un double tiret ne sont pas pris en charge.

‍

Créez cette audience en quelques secondes avec QAiry

‍

La plupart des erreurs ci-dessus viennent de petits décalages entre le SQL et votre modèle de données réel. QAiry transforme une demande en langage courant en SQL et en data extensions SFMC prêts pour la production : vous décrivez l'audience et vous relisez le résultat, au lieu de corriger la syntaxe. Découvrez aussi comment générer du SQL SFMC à partir d'une phrase en français.

Envie d'essayer ? Installez QAiry gratuitement dans votre compte SFMC, ou regardez d'abord une démo produit.