Funciones de conversión — Referencia de SQL en Marketing Cloud | Cleon

Las funciones de conversión transforman un valor de un tipo a otro. En MC SQL las opciones son CAST (SQL estándar, portátil), CONVERT (T-SQL con códigos de estilo para formateo de fecha), y las variantes TRY_* que devuelven NULL en falla en lugar de tirar error. La mayoría de los bugs de conversión son silenciosos: el motor sí coerce tipos implícitamente cuando no lo pedís, y elige una dirección que a veces es correcta y a veces catastrófica.

Sintaxis oficial

-- CAST: estándar, portátil, sin códigos de estilo
SELECT CAST(SubscriberKey AS NVARCHAR(255)) AS KeyAsString
FROM master_subscribers;

SELECT CAST('2026-05-07' AS DATE) AS ParsedDate;

-- CONVERT: T-SQL específico, soporta códigos de estilo para formateo de fecha
SELECT CONVERT(VARCHAR, GETDATE(), 120) AS Iso8601;        -- 2026-05-07 14:23:11
SELECT CONVERT(VARCHAR, GETDATE(), 23)  AS DateOnly;       -- 2026-05-07
SELECT CONVERT(VARCHAR, GETDATE(), 101) AS UsFormat;       -- 05/07/2026
SELECT CONVERT(DECIMAL(18,2), '1234.5678');                -- 1234.57

-- TRY_CAST / TRY_CONVERT: devuelven NULL en falla de conversión
-- (en lugar de tirar error y matar la Activity)
SELECT TRY_CAST(LegacyAge AS INT) AS AgeOrNull
FROM master_subscribers;
-- Donde LegacyAge a veces es '42', a veces 'unknown', a veces vacío

-- COALESCE la falla a un default sensato
SELECT COALESCE(TRY_CAST(LegacyAge AS INT), 0) AS Age
FROM master_subscribers;

El set soportado:

| Función | Qué hace | En falla | |---|---|---| | CAST(value AS type) | Conversión explícita | Tira error, falla la Activity | | CONVERT(type, value) | Igual que CAST, sintaxis T-SQL | Tira error | | CONVERT(type, value, style) | Conversión con estilo de formato (strings de fecha) | Tira error | | TRY_CAST(value AS type) | Como CAST pero devuelve NULL en falla | Devuelve NULL | | TRY_CONVERT(type, value, style) | Como CONVERT pero devuelve NULL en falla | Devuelve NULL |

Códigos de estilo de fecha útiles (lista completa en Salesforce Help):

| Estilo | Formato | Ejemplo | |---|---|---| | 120 | ISO 8601 con hora | 2026-05-07 14:23:11 | | 121 | ISO 8601 con milisegundos | 2026-05-07 14:23:11.000 | | 23 | ISO 8601 solo fecha | 2026-05-07 | | 101 | US mm/dd/yyyy | 05/07/2026 | | 103 | UK dd/mm/yyyy | 07/05/2026 | | 112 | ISO básico yyyymmdd | 20260507 | | 0 | Default mon dd yyyy hh:miAM/PM | May 7 2026 2:23PM |

Referencia:

Salesforce Help — Sintaxis T-SQL soportada (sección de funciones) ↗

Lo que sobrevive en producción

`TRY_CAST` sobre `CAST` cuando el origen está sucio

Una sola fila mala en el origen — 'unknown' en una columna que intentaste CAST a INT — va a fallar la Activity entera y no rollbackea nada (porque no hay transacciones, ver gotchas — #1). Usá TRY_CAST cuando el origen es cualquier cosa distinta de tu propio data limpio.

-- EN RIESGO — una sola fila malformada en cualquier parte de master_subscribers
-- mata la Activity en la fila N, dejando N-1 filas medio-escritas
INSERT INTO de_stg_ages
SELECT
  SubscriberKey,
  CAST(LegacyAge AS INT) AS Age
FROM master_subscribers;

-- DURABLE — las filas malas obtienen NULL, la Activity completa,
-- podés investigar los NULLs después
INSERT INTO de_stg_ages
SELECT
  SubscriberKey,
  TRY_CAST(LegacyAge AS INT) AS Age
FROM master_subscribers;

-- DURABLE + DEFAULT — las filas malas obtienen un valor centinela
INSERT INTO de_stg_ages
SELECT
  SubscriberKey,
  COALESCE(TRY_CAST(LegacyAge AS INT), -1) AS Age   -- -1 marca "no parseable"
FROM master_subscribers;

La versión TRY_CAST exitosa y te da un conteo de filas con NULLs (o centinelas) que podés inspeccionar. La versión CAST surfacea la fila mala fallando todo el pipeline — útil en desarrollo, peligroso en producción scheduleada.

Siempre casteá `SubscriberKey` a `NVARCHAR(255)` en los dos lados de un join

SubscriberKey se guarda como string pero seguido se joinea contra IDs externos enteros, llevando a miscounts silenciosos. El patrón está en la referencia de JOIN pero vale repetirlo acá como regla de conversión:

-- DEFENSIVO — cast explícito en los dos lados + trim
SELECT s.SubscriberKey, e.LoyaltyTier
FROM _Subscribers s
INNER JOIN ext_loyalty e
  ON LTRIM(RTRIM(CAST(s.SubscriberKey AS NVARCHAR(255))))
   = LTRIM(RTRIM(CAST(e.UserId AS NVARCHAR(255))));

Ver JOIN, Funciones de string, y gotchas — #9.

La conversión implícita elige una dirección — y no siempre es la segura

Cuando comparás '42' = 42 (string vs int), el motor castea implícitamente un lado. En T-SQL la regla es generalmente "el string se convierte a int" — lo que falla en la fila donde LegacyAge es 'unknown' y mata la Activity. Hacé la conversión explícita para que sepas en qué dirección va.

-- EN RIESGO — conversión implícita, falla en filas donde LegacyAge no es numérico
WHERE LegacyAge = 18

-- EXPLÍCITO — TRY_CAST maneja las filas malas elegantemente
WHERE TRY_CAST(LegacyAge AS INT) = 18

-- TAMBIÉN EXPLÍCITO — comparar strings en los dos lados (sin necesidad de conversión)
WHERE LegacyAge = '18'

Elegí una de las versiones explícitas según lo que la columna realmente contenga. No dejes que la conversión implícita decida por vos.

Códigos de estilo de `CONVERT` para formateo de fecha — elegí ISO 8601 (estilo 120 o 23)

Cuando convertís fechas a strings (para export, logs, naming de archivos), el código de estilo importa. La mayoría de los formatos internacionales son ambiguos (05/07/2026 es 7 de mayo en US, 5 de julio en UK). ISO 8601 (2026-05-07) no es ambiguo y ordena correctamente como string.

-- EVITAR — locale-específico, ordena incorrectamente como string
SELECT CONVERT(VARCHAR, OrderDate, 101) AS DateForExport;  -- 05/07/2026

-- PREFERIR — ISO 8601, no ambiguo, ordena como string
SELECT CONVERT(VARCHAR, OrderDate, 23) AS DateForExport;   -- 2026-05-07

El costo es una diferencia de cuatro caracteres en el código de estilo; el ahorro es un sistema downstream que ordena los strings de OrderDate correctamente sin convertir de vuelta a fechas.

WATCH OUT

Cuando hacés CAST de un VARCHAR a un tipo numérico, los espacios al principio y al final pueden causar falla. CAST(' 42' AS INT) puede tener éxito en algunos tenants y fallar en otros. La defensa: LTRIM(RTRIM()) primero, o usá TRY_CAST así una fila que falla se vuelve NULL en lugar de romper la Activity:

-- EN RIESGO — números con whitespace pueden fallar el cast
SELECT CAST(LegacyField AS INT) AS Cleaned
FROM imported_csv;

-- DURABLE — trim primero, después try-cast
SELECT TRY_CAST(LTRIM(RTRIM(LegacyField)) AS INT) AS Cleaned
FROM imported_csv;

Decisión rápida

Usá TRY_CAST / TRY_CONVERT cuando:

El dato de origen fue importado de sistemas externos (CSV, drop FTP, export de CRM).
Una fila que falla mataría una Activity scheduleada de producción.
Preferís ver NULLs que podés inspeccionar a una Failed Activity step.

Usá CAST (sin TRY_) cuando:

El origen es tu propio DE stagéado que ya fue validado.
Un cast que falla realmente significa un bug que querés surfacear inmediatamente (entorno de desarrollo).

Usá CONVERT en lugar de CAST cuando:

Necesitás códigos de estilo para formateo de string de fecha.
Si no, preferí CAST por portabilidad.

Siempre envolvé claves de join en LTRIM(RTRIM(CAST(... AS NVARCHAR(255)))) cuando:

Joineás SubscriberKey o cualquier ID externo entre DEs.

Relacionado

Basics — subset de T-SQL soportado
SELECT — CAST en proyección
WHERE — conversión implícita en comparaciones de filtro
JOIN — CAST en los dos lados de claves de join
Funciones de string — LTRIM(RTRIM()) compañero de CAST
Funciones numéricas — CAST a DECIMAL para precisión de división
MC SQL gotchas — ver #1 (sin transacciones hace que los casts fallidos sean catastróficos), #9 (casteo de SubscriberKey)

Próximas páginas de referencia de funciones: Aggregate · Null Functions.

Más snippets how-to para debugging común en producción — sends de email, largo de valores, alcance de contactos, etc.