Puf, trabajar así es mortal. Todo eso para hacer una simple consulta. ¿Por qué no te haces una función para ejecutar consultas de SQL directamente, debidamente escapadas (como lo harías en Python o en Perl, por ejemplo), que te devuelva los resultados en estructuras de datos nativas, y además usas simplemente CALL y SELECT?
En uno de mis marco de trabajo en PHP, por ejemplo, tengo funciones que me permiten hacer cosas como:
DBExecute('CALL Procedimiento(?, ?, @salida)', $param1, $param2);
Esta función sustituye los signos de pregunta por la representación correcta en SQL de $param1 y $param2 según su tipo. Si el procedimiento devolviera una tabla, podría haber usado DBGetTable (entre otras) para obtenerla directamente como una tabla nativa de PHP. Y si luego quiero consultar @salida, por ejemplo para mostrarlo en alguna parte en un caso muy simple, sólo tengo que hacer:
echo DBGetValue('SELECT @salida');
Por supuesto estas funciones trabajan solamente con una conexión de base de datos que es global en esta aplicación, pero supongo que coges el concepto. La idea es que, si la interfaz con la base de datos en tu lenguaje/con tu librería (en este caso VB+ODBC) es un rollo patatero, que te construyas una interfaz más cómoda para utilizar la base de datos.
En el caso de esta aplicación que comento, la interfaz era una capa de abstracción de base de datos que era medianamente cómoda pero insegura (sin formas adecuadas de insertar parámetros escapados debidamente), así que me hice unas funciones para utilizar la base de datos con la misma soltura con la que utilizo cualquier otra facilidad del lenguaje.
Un saludo,
Miguel Pérez
Afina Sistemas - Partner de MySQL en España
Edited 2 time(s). Last edit at 08/01/2008 02:20AM by Miguel Perez.