campo bdd integer, delphi string sin error

[CarlosHernandez]

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???

Código Delphi [-]
var
carnet,prestamo:string;
begin

with IBQuery1 do begin
close;
SQL.Clear;                                        //
SQL.Add('select * from Carnetvis where(ncarnet=:parnumc and tipocarnet='+QuotedStr(combobox2.Text)+')');
Prepare;
ParamByName('parnumc').Asstring:=edit1.text;
open;
carnet:=inttostr(fieldbyname('ncarnet').Asinteger);
prestamo:=fieldbyname('prestamo').AsString;
end;
Label1.caption:=carnet;

end;

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....

[roman]

Empezado por CarlosHernandez

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???

Siempre y cuando introduzcas un número correcto, no tiene porque haber ningun problema. El método AsString convierte el dato textual al formato requerido por el campo subyacente.

Intenta colocar un texto que no corresponda a un número y seguro que ahí verás que sí hay error.

// Saludos

[CarlosHernandez]

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??

[[Al González]]

¡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:

Código Delphi [-]
ParamByName ('CampoNumerico').AsString := Edit1.Text;

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:

Código Delphi [-]
ParamByName ('CampoNumerico').AsFloat := StrToFloat (Edit1.Text);

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!

Código Delphi [-]
...
procedure TParam.SetAsBoolean(Value: Boolean);
begin
  FDataType := ftBoolean;
  Self.Value := Value;
end;

procedure TParam.SetAsFloat(const Value: Double);
begin
  FDataType := ftFloat;
  Self.Value := Value;
end;

procedure TParam.SetAsString(const Value: string);
begin
  if FDataType <> ftFixedChar then FDataType := ftString;
  Self.Value := Value;
end;

procedure TParam.SetAsVariant(const Value: Variant);
begin
  if ParamRef = Self then
  begin
    FBound := not VarIsClear(Value);
    FNull := VarIsClear(Value) or VarIsNull(Value);
    if FDataType = ftUnknown then
      case VarType(Value) of
        varSmallint, varShortInt, varByte: FDataType := ftSmallInt;
        varWord, varInteger: FDataType := ftInteger;
        varCurrency: FDataType := ftBCD;
        varLongWord, varSingle, varDouble: FDataType := ftFloat;
  ...
end;
...

(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.

[roman]

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

Código Delphi [-]
Query.ParamByName(...).AsXYZ := valor;

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:

Código SQL [-]
update productos
set precio = "1123.58"
where ...

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

Código Delphi [-]
Table.FieldByName('precio').AsString := '1123.58';

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

[[Al González]]

Empezado por roman

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.

Podría ser, pero cuando uno mismo ha definido los parámetros en tiempo de diseño, como que no esperas que al asignarles valor en tiempo de ejecución Delphi modifique alguna de esas definiciones. Es decir, habiendo establecido los parámetros como lo hacemos con los campos persistentes, bajo conocimiento del tipo específico que tienen.

No lo sé, es razonable y a la vez curioso. Pero ahora me percato que la propia ayuda de TParam lo advierte:

Setting AsFloat sets the DataType property to ftFloat.

Que pases buena noche Román, yo todavía trabajaré un rato más. Con un ojo al gato y otro al garabato, como solía decirme mi madre cuando era yo un chaval.