FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
campo bdd integer, delphi string sin error
tengo un campo integer en firebird, pero en la programacion de delphi lo trato como un campo string, cuando realizo la busqueda me muestra el registro solicitado, mi duda es si en la tabla esta como integer y yo en delphi lo trato string porque igual lo muestra y lo amacena sin dar ningun tipo de error???
pregunto por la curiosidad y ademas porque ya en mi sistema tengo el campo ncarnet varchar, y lo cambie a integer y el sistema funciona todo perfecto despues que actualizo los query dbexpress.... |
#2
|
||||
|
||||
Cita:
Intenta colocar un texto que no corresponda a un número y seguro que ahí verás que sí hay error. // Saludos |
#3
|
||||
|
||||
gracias roman si ya lo probe y efectivamente me da el error, esto quiere decir que lo puedo trabajar en programacion de las dos forma (string e integer) sin error?? esto tambien pasa con otros tipos de datos??
|
#4
|
||||
|
||||
¡Hola!
Cuando se trata de campos, las propiedades AsXXX ofrecen una manera muy eficaz de leer y asignar valores. Pero existe algo de considerar en las propiedades AsXXX de los parámetros, que explico en seguida. Hace varios días, durante una asesoría a un colega, encontramos que había problemas con el método AsString de un parámetro al usar una sintaxis como: Resulta que la base de datos era Paradox vía BDE, y al tratar de ejecutar la sentencia SQL el servidor la rechazaba por un problema de tipos. El campo era flotante, y, sólo por intentar algo diferente, sugerí cambiar la sentencia por: Y entonces funcionó. En ese momento adjudiqué el problema por completo a la BDE. Pero leyendo ahora este hilo me entró la sospecha de algo relacionado a la propiedad DataType de los parámetros, y dicha sospecha se ha confirmado. Resulta que los métodos SetAsXXX de TParam, que son las rutinas de escritura de sus propiedades AsXXX, ¡cambian el valor de DataType en función de la propiedad usada para la asignación! (unidad DB.pas de Delphi 7) Entonces eso explica, en parte, por qué la BDE / Paradox rechazaba aquella sentencia, en la que se intentaba asignar valor a un parámetro numérico con la propiedad AsString de ese TParam. Nunca he tenido este problema con Firebird vía IBX o dbExpress (creo), así que ya había dado por hecho que estas propiedades AsXXX eran meros convertidores (como las de TField). Pero con esto que sale a la luz, ¿deberíamos usarlas con precautoria atención ante la posibilidad de cambiar de motor? Incluso, según se ve, hasta la misma propiedad Value lo hace (SetAsVariant es su método de escritura). ¿Está mal que los métodos SetAsXXX de TParam modifiquen la propiedad DataType? Sin razonarlo mucho, pareciera que sí, pero alguna explicación deberá existir. Por alguna razón, para la VCL los objetos TParam son de "menos valía" que los TField. De hecho hay un divertido y "criminal" mecanismo de pérdida de parámetros en la mayoría de las clases que implementan el método PSSetParams, cuando nos olvidamos de establecerlos correctamente en el lado cliente. Creo que habría que investigar cómo trata cada tecnología (BDE, IBX, ADO, dbExpress) a los parámetros, para tener una idea clara de la seguridad que ofrecen las propiedades AsXXX y Value de TParam. Un abrazo parametrizado. Al González. Última edición por Al González fecha: 17-02-2009 a las 05:01:53. |
#5
|
||||
|
||||
Hola,
Es cierto Al, el tratamiento a los campos es distinto que a los parámetros. Tal como yo lo decía es incorrecto, ya que, como bien notas, las propiedades AsXXX no hacen una conversión sino que simplemente cambian el tipo de datos (DataType). Ahora, no me parece descabellado. Más bien habría que ver porqué TField no lo hace. Si yo escribo
explícitamente estoy diciendo que quiero tratar el parámetro como un tipo XYZ; ¿por qué, entonces no había de hacerse el cambio de DataType? Pero no deja de ser raro que el BDE no acepte el paso de un parámetro float como AsString puesto que el motor en sí si acepta consultas como:
siendo precio un campo numérico. Por otra parte, los métodos SetAsXYZ de TField en realidad sólo lanzan una excepción; es decir que están hechos para ser redefinidos. Entonces, cuando hacemos algo como
en realidad estamos llamando al método SetAsString, no de TField, sino de TFloatField. Cuando abrimos la tabla, se crean los campos del tipo adecuado según especifique la tabla física, de manera que ya se sabe de antemano que el campo real es de tipo float, y por tanto, el valor que se dé, debe convertirse a ese tipo de datos antes de mandarlo a la base. Pero en el caso de un Query, no se sabe de antemano a qué tipo de datos corresponde el parámetro en la base, así que tiene que confiar en lo que le decimos y cambiar el valor de DataType. Bueno, desde luego estoy especulando, pero creo que por ahí va el porqué TParam ajusta DataType y TField (o sus descendientes) no. // Saludos |
#6
|
||||
|
||||
Cita:
No lo sé, es razonable y a la vez curioso. Pero ahora me percato que la propia ayuda de TParam lo advierte: Cita:
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
string a integer? | acertij022 | Varios | 4 | 26-02-2008 23:24:30 |
String a Integer | tuflotas | Varios | 9 | 22-01-2008 21:09:34 |
Integer a String en PHP | noshy | PHP | 13 | 06-08-2007 19:26:36 |
de String a Integer!! | kye_z | Varios | 2 | 20-11-2004 20:04:36 |
Convertir campo tipo number de oracle a integer o string | Sóstrato | OOP | 1 | 13-06-2003 09:18:55 |
|