Powerbuilder con MySql
Estoy desarrollando en PowerBuilder 5.02 y quiero usar una BD en mysql (a través de ODBC) para estudiar su rendimiento. Mi sorpresa ha sido que al usar sentencias embebidas en PB no se obtienen los resultados deseados. He aquí el problema:
long ll_pk // variable a grabar por SQL directo
ll_pk = 56 //cargo la variable
INSERT INTO <TABLA> (campo) values (:ll_pk); //lanzo la sentencia
esta sentencia me graba CAMPO = 5 ?????? Se ha comido el 6
Bien, pues esto pasa con todos los valores INT que use, en los que siempre solo me graba la primera cifra y se come el resto
he descubierto que si convierto a cadena ll_pk funciona correctamente, pero eso es inadmisible, porque el programa ha de ser transportable a SQL-ANYWHERE y a INFORMIX. Por cierto que con estas BD'S todo va correctamente.
long ll_pk // variable a grabar por SQL directo
ll_pk = 56 //cargo la variable
INSERT INTO <TABLA> (campo) values (:ll_pk); //lanzo la sentencia
esta sentencia me graba CAMPO = 5 ?????? Se ha comido el 6
Bien, pues esto pasa con todos los valores INT que use, en los que siempre solo me graba la primera cifra y se come el resto
he descubierto que si convierto a cadena ll_pk funciona correctamente, pero eso es inadmisible, porque el programa ha de ser transportable a SQL-ANYWHERE y a INFORMIX. Por cierto que con estas BD'S todo va correctamente.
2 respuestas
Respuesta de bankhacker
1
No he trabajado nunca con PowerBuilder, pero por lo que me comentas, el problema puede estar simplemente en el tipo de variables y las conversiones entre tipos.
En PHP, que es con lo que yo programo, siempre se trabaja con variables de tipo genérico, que admiten tanto enteros como cadenas. Por este motivo, no encontramos este problema con PHP, puesto que cualquier resultado de una Query se trata como una cadena, o un array de cadenas.
Te recomiendo que hagas lo mismo con PowerBuilder. Recoge el resultado de la query siempre como una cadena, y luego lo conviertes controladamente al tipo que tu quieras.
Suerte!
En PHP, que es con lo que yo programo, siempre se trabaja con variables de tipo genérico, que admiten tanto enteros como cadenas. Por este motivo, no encontramos este problema con PHP, puesto que cualquier resultado de una Query se trata como una cadena, o un array de cadenas.
Te recomiendo que hagas lo mismo con PowerBuilder. Recoge el resultado de la query siempre como una cadena, y luego lo conviertes controladamente al tipo que tu quieras.
Suerte!
Respuesta
1
Lo más probable es que sea un problema del propio driver ODBC de MySQL.
PowerBuilder utiliza drivers nativos para acceder a las API de las BDs más conocidas : Oracle, SQL Server, Sybase, y utiliza un driver genérico ODBC para el resto de bases de datos. Si fuera un error del driver de PB, con lo grave que es los usuarios habrían puesto el grito en el cielo, por lo que deduzco que es problema del driver. Intenta bajar una version más actualizada, o bien un driver ODBC alternativo. Intenta jugar con el atributo DisableBind del DbParm, igual es un problema del binding de variables y si lo desactivas funciona.
Si en ultima instancia no funciona, sustituye los INSERT con SQL embebido por DataStores, esto te obligara a crear DataObjects pero el rendimiento y la portabilidad son mucho mayores. Yo hice una aplicación que iba contra Oracle, Watcom y SQL Server y tuve problemas parecidos, acabé haciendo datawindows invisibles para actualizar (era la version 4 y no había DataStores).
PowerBuilder utiliza drivers nativos para acceder a las API de las BDs más conocidas : Oracle, SQL Server, Sybase, y utiliza un driver genérico ODBC para el resto de bases de datos. Si fuera un error del driver de PB, con lo grave que es los usuarios habrían puesto el grito en el cielo, por lo que deduzco que es problema del driver. Intenta bajar una version más actualizada, o bien un driver ODBC alternativo. Intenta jugar con el atributo DisableBind del DbParm, igual es un problema del binding de variables y si lo desactivas funciona.
Si en ultima instancia no funciona, sustituye los INSERT con SQL embebido por DataStores, esto te obligara a crear DataObjects pero el rendimiento y la portabilidad son mucho mayores. Yo hice una aplicación que iba contra Oracle, Watcom y SQL Server y tuve problemas parecidos, acabé haciendo datawindows invisibles para actualizar (era la version 4 y no había DataStores).