¿Te ha pasado que una consulta en SAP HANA devuelve cientos de registros correctamente, pero al consumirla desde PHP mediante ODBC solamente recibes uno?
Eso fue exactamente lo que ocurrió en este caso: una consulta en SAP HANA tenía 902 registros, pero desde PHP, al incluir la descripción del artículo OITM."ItemName", odbc_fetch_array() solamente recuperaba 1 registro.
Después de varias pruebas se pudo determinar que no era un problema de memoria, SQL, JOIN, PHP ni del while.
La solución fue configurar correctamente el controlador SAP HANA ODBC para manejar los caracteres mediante UTF-8:
CHAR_AS_UTF8=true
manteniendo:
EnableArrayFetch=1
La configuración se aplicó tanto en Linux Mint como en Windows 10.
🚨 El problema
La consulta original era similar a:
SELECT
a."ItemCode",
b."ItemName",
a."Price",
a."PriceList",
c."ListName"
FROM ITM1 a
INNER JOIN OITM b
ON a."ItemCode" = b."ItemCode"
INNER JOIN OPLN c
ON a."PriceList" = c."ListNum"
WHERE a."PriceList" = 1
AND IFNULL(a."Price", 0) > 0;
En SAP HANA la consulta contenía 902 artículos con precio.
Sin embargo, PHP solamente recibía:
1 registro
y no aparecía ningún error ODBC.
El código PHP era completamente normal:
while ($row = odbc_fetch_array($stmt)) {
$data[] = [
'ItemCode' => $row['ItemCode'],
'ItemName' => $row['ItemName'],
'Price' => (float) $row['Price'],
'PriceList' => (int) $row['PriceList'],
'ListName' => $row['ListName'],
];
}
🔍 Primero: comprobar si realmente existen los registros
Antes de culpar a PHP u ODBC, se comprobó directamente en HANA:
SELECT COUNT(*) AS "Total"
FROM ITM1
WHERE "PriceList" = 1
AND IFNULL("Price", 0) > 0;
Resultado:
902
Por lo tanto, los datos sí existían.
🧪 Diagnóstico paso a paso
Para encontrar el problema se fue simplificando la consulta.
1️⃣ Solamente ITM1
SELECT
"ItemCode",
"Price",
"PriceList"
FROM ITM1
WHERE "PriceList" = 1
AND IFNULL("Price", 0) > 0;
Desde PHP:
TOTAL: 902
✅ ITM1 funcionaba correctamente.
2️⃣ Agregar el JOIN con OITM
Se añadió:
INNER JOIN OITM b
ON a."ItemCode" = b."ItemCode"
pero solamente se recuperó el código:
SELECT
a."ItemCode",
b."ItemCode"
FROM ITM1 a
INNER JOIN OITM b
ON a."ItemCode" = b."ItemCode"
WHERE a."PriceList" = 1
AND IFNULL(a."Price", 0) > 0;
Resultado:
TOTAL: 902
✅ El JOIN con OITM también funcionaba.
⚠️ 3️⃣ Agregar ItemName
El problema apareció cuando se añadió:
b."ItemName"
La consulta:
SELECT
a."ItemCode",
b."ItemName"
FROM ITM1 a
INNER JOIN OITM b
ON a."ItemCode" = b."ItemCode"
WHERE a."PriceList" = 1
AND IFNULL(a."Price", 0) > 0;
Desde PHP solamente devolvía:
TOTAL: 1
🎯 Aquí quedó localizado el problema.
No era el JOIN.
No era ITM1.
No era OPLN.
No era memoria.
El comportamiento aparecía específicamente al recuperar el contenido de:
OITM."ItemName"
🧠 Una pista importante: los caracteres especiales
Durante las pruebas también apareció algo muy revelador.
En SAP HANA el texto era:
REV 14±2
pero PHP recibía:
REV 14±2
Eso indicaba claramente un problema de codificación de caracteres entre:
SAP HANA
↓
HDBODBC
↓
PHP
↓
JSON
↓
DataTables
Además, el problema no generaba un error ODBC tradicional.
Por eso era especialmente difícil de localizar.
🐧 Solución en Linux Mint
Primero se comprobó la configuración de unixODBC:
odbcinst -j
La salida mostraba:
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
USER DATA SOURCES..: /home/usuario/.odbc.ini
El DSN utilizado estaba en:
/etc/odbc.ini
La configuración original era:
[mi_dsn_hana]
Driver=SAP HANA
ServerNode=SERVIDOR_HANA:30015
Se añadió:
CHAR_AS_UTF8=true
Quedando:
[mi_dsn_hana]
Driver=SAP HANA
ServerNode=SERVIDOR_HANA:30015
CHAR_AS_UTF8=true
El driver utilizado estaba definido en:
/etc/odbcinst.ini
con:
[HANA_ODBC]
Description=SAP HANA ODBC Driver
Driver=/ruta/al/cliente-hana/libodbcHDB.so
🔎 Comandos útiles para localizar ODBC en Linux
Para saber dónde están los archivos:
odbcinst -j
Para ver el DSN:
cat /etc/odbc.ini
Para ver los drivers:
cat /etc/odbcinst.ini
Para buscar configuraciones relacionadas con HANA:
grep -RniE "HDB|HANA|CHAR_AS_UTF8|char_as_utf8|ServerNode|Driver" \
/etc/odbc.ini \
/etc/odbcinst.ini \
~/.odbc.ini 2>/dev/null
Para listar los DSN:
odbcinst -q -s
🪟 Solución en Windows 10
En Windows se comprobó primero la arquitectura de PHP:
php -i | findstr /I "Architecture"
Resultado:
Architecture => x64
Por lo tanto se utilizó el administrador ODBC de 64 bits:
C:\Windows\System32\odbcad32.exe
El DSN utilizado era:
mi_dsn_hana
y estaba registrado en:
HKLM\SOFTWARE\ODBC\ODBC.INI\mi_dsn_hana
Al consultar el registro:
reg query "HKLM\SOFTWARE\ODBC\ODBC.INI\mi_dsn_hana" /s
se encontró, entre otros valores:
Driver C:\Program Files\SAP\hdbclient\libodbcHDB.dll
Host SERVIDOR_HANA
PortNumber 30015
EnableArrayFetch 1
ArrayFetchSize 5000
💾 Antes de modificar el registro: hacer respaldo
Siempre es recomendable guardar una copia del DSN.
reg export "HKLM\SOFTWARE\ODBC\ODBC.INI\mi_dsn_hana" "%USERPROFILE%\Desktop\mi_dsn_hana-backup.reg"
Windows responderá:
La operación se completó correctamente.
Así se dispone de un archivo de respaldo en el escritorio.
⚙️ Agregar CHAR_AS_UTF8 en Windows
Se agregó directamente al registro:
reg add "HKLM\SOFTWARE\ODBC\ODBC.INI\mi_dsn_hana" /v CHAR_AS_UTF8 /t REG_SZ /d true /f
Para comprobarlo:
reg query "HKLM\SOFTWARE\ODBC\ODBC.INI\mi_dsn_hana" /v CHAR_AS_UTF8
El resultado esperado es:
CHAR_AS_UTF8 REG_SZ true
✅ Configuración aplicada correctamente.
🔄 Reiniciar Apache
Después de modificar el DSN, es importante reiniciar Apache/XAMPP para que PHP cree una nueva conexión ODBC.
Desde XAMPP:
Stop Apache
Start Apache
O, si Apache está instalado como servicio:
net stop Apache2.4
net start Apache2.4
El nombre del servicio puede variar según la instalación.
⚙️ ¿Qué pasó con EnableArrayFetch?
El DSN de Windows ya tenía:
EnableArrayFetch=1
y:
ArrayFetchSize=5000
Durante las pruebas se decidió mantenerlo activado.
La configuración final quedó:
CHAR_AS_UTF8=true
EnableArrayFetch=1
Esto mismo se mantuvo tanto en Linux como en Windows.
No fue necesario desactivar EnableArrayFetch.
💻 La función PHP no necesitó cambios especiales
Una vez solucionada la configuración del ODBC, la consulta PHP puede seguir siendo una consulta normal:
static public function ctrMostrarListaPrecio($conn, int $id)
{
$sql = '
SELECT
a."ItemCode",
b."ItemName",
a."Price",
a."PriceList",
c."ListName"
FROM ITM1 a
INNER JOIN OITM b
ON a."ItemCode" = b."ItemCode"
INNER JOIN OPLN c
ON a."PriceList" = c."ListNum"
WHERE a."PriceList" = ?
AND IFNULL(a."Price", 0) > 0
';
$stmt = odbc_prepare($conn, $sql);
if (!$stmt) {
throw new Exception(
'Error ODBC prepare: ' . odbc_errormsg($conn)
);
}
if (!odbc_execute($stmt, [$id])) {
throw new Exception(
'Error ODBC execute: ' . odbc_errormsg($conn)
);
}
$data = [];
while ($row = odbc_fetch_array($stmt)) {
$data[] = [
'ItemCode' => $row['ItemCode'],
'ItemName' => $row['ItemName'],
'Price' => (float) $row['Price'],
'PriceList' => (int) $row['PriceList'],
'ListName' => $row['ListName'],
];
}
return $data;
}
La solución estuvo en la configuración del HDBODBC, no en cambiar la consulta.
🧪 Otra prueba importante: comprobar si era memoria
También se revisó la memoria de PHP:
echo memory_get_usage(true);
Durante las pruebas se obtuvo aproximadamente:
2097152 bytes
Y el pico:
2097152 bytes
No hubo incremento importante al procesar los registros.
Por lo tanto:
❌ No era falta de memoria.
❌ No era que 902 registros fueran demasiados.
❌ No era el while.
❌ No era odbc_prepare().
❌ No era odbc_execute().
❌ No era el JOIN.
✅ El comportamiento estaba relacionado con el tratamiento de caracteres por HDBODBC.
🛠️ Diagnóstico recomendado para futuros problemas
Cuando PHP y SAP HANA devuelvan menos registros de los esperados, no hay que asumir inmediatamente que el problema está en SQL.
Una buena estrategia es ir agregando las columnas progresivamente.
Primero:
SELECT
"ItemCode"
FROM ITM1
WHERE "PriceList" = 1;
Después:
SELECT
a."ItemCode",
b."ItemCode"
FROM ITM1 a
INNER JOIN OITM b
ON a."ItemCode" = b."ItemCode"
WHERE a."PriceList" = 1;
Después:
SELECT
a."ItemCode",
b."ItemName"
FROM ITM1 a
INNER JOIN OITM b
ON a."ItemCode" = b."ItemCode"
WHERE a."PriceList" = 1;
De esta forma puedes identificar exactamente qué columna provoca el comportamiento.
En este caso:
ITM1 → 902
ITM1 + OITM.ItemCode → 902
ITM1 + OITM.ItemName → 1
Ese pequeño experimento permitió descubrir rápidamente que había que investigar el tratamiento del campo de texto.
📌 Configuración final
Después de todas las pruebas, la configuración que quedó funcionando fue:
CHAR_AS_UTF8=true
EnableArrayFetch=1
Linux Mint
Archivo:
/etc/odbc.ini
Configuración:
[mi_dsn_hana]
Driver=SAP HANA
ServerNode=SERVIDOR_HANA:30015
CHAR_AS_UTF8=true
Windows 10
Registro:
HKLM\SOFTWARE\ODBC\ODBC.INI\mi_dsn_hana
Valor:
CHAR_AS_UTF8 REG_SZ true
Manteniendo:
EnableArrayFetch REG_SZ 1
✅ Conclusión
El problema parecía inicialmente un problema de PHP porque:
while ($row = odbc_fetch_array($stmt))
solamente recuperaba un registro.
Sin embargo, las pruebas demostraron que SAP HANA sí tenía 902 registros y que ODBC podía recorrerlos correctamente mientras no se solicitara directamente el contenido de ItemName.
La pista definitiva fue que los textos con caracteres especiales aparecían alterados, por ejemplo:
14±2
se recibía como:
14±2
La corrección fue configurar el controlador de SAP HANA para trabajar con UTF-8:
CHAR_AS_UTF8=true
manteniendo:
EnableArrayFetch=1
La configuración fue aplicada tanto en Linux Mint como en Windows 10.
💡 Moraleja: cuando PHP + ODBC + SAP HANA devuelve menos filas de las esperadas, especialmente al trabajar con campos NVARCHAR o textos con caracteres especiales, conviene revisar primero la configuración del HDBODBC antes de modificar la consulta o asumir que existe un problema de memoria.
🚀 Resumen rápido
Linux
sudo cp /etc/odbc.ini /etc/odbc.ini.bak
sudo nano /etc/odbc.ini
Agregar:
CHAR_AS_UTF8=true
Windows 10
Respaldar:
reg export "HKLM\SOFTWARE\ODBC\ODBC.INI\mi_dsn_hana" "%USERPROFILE%\Desktop\mi_dsn_hana-backup.reg"
Agregar:
reg add "HKLM\SOFTWARE\ODBC\ODBC.INI\mi_dsn_hana" /v CHAR_AS_UTF8 /t REG_SZ /d true /f
Comprobar:
reg query "HKLM\SOFTWARE\ODBC\ODBC.INI\mi_dsn_hana" /v CHAR_AS_UTF8
Resultado esperado:
CHAR_AS_UTF8 REG_SZ true
Configuración final:
CHAR_AS_UTF8=true
EnableArrayFetch=1
🔧 PHP + SAP HANA + ODBC + UTF-8: un pequeño parámetro del driver puede hacer toda la diferencia.
