Después de repasar todo lo aportado por los compañeros y mirar detenidamente el datadef.pdf, estamos en la misma situación. En resumen:

Dialecto 1 con precision mayor a 9 usando DOUBLE PRECISION, siempre tendrá problemas de decimales que pueden ser redondeado donde legalmente se pueda (como bien dijo Casimiro, en los totales; nunca se puede redondear en cálculos intermedios)

Dialecto 3 con precisión mayor a 9 , da igual si se usa NUMERIC(10,2), DECIMAL(10,2) o DOUBLE PRECISION, Firebird usará un INT64 internamente para representar el número y no habrá pérdida de decimales.

Si la precisión es menor o igual a 9, internamente se usará smallint, integer, double precision, etc. dependiendo del tipo usado. En este caso no queda más remedio que ver el pdf para entender como se guarda internamente.

Saludos

ummm, pues no, nunca me ha hecho falta usar esa propiedad.

y de guerra santa? no tienes ganas? :D

Que efecto tiene asignar la propiedad currency a True en un field???

... no lo sabes tú bien, con sangre y todo de por medio... pero me contengo :p.

Teniendo un campo Float (TFloatField), da la apariencia de ser un Currency: muestra el símbolo de la moneda y dos decimales, al editar también se mantiene este formato (si EditFormat y DisplayFormat están en blanco).

Por eso lo pregunté, ya que si es un double precision y estableces la propiedad en True, el propio TField puede camuflar el valor real que tiene asignado. Por ejemplo:

valor real 2,539
valor mostrado en el DBedit (por currency:= true) 2,54


Saludos

Esto se puso interesante , pues aqui va otra pregunta si uso double precision el problema desaparecera o no ? bueno eso lo voy a probar luego en el trabajo , pero a ud que ya tienen mucha experiencia en esto de los dialectos , cuales son los problemas mas comunes de migrar de dialecto 1 a dialecto 3 , hay que cambiar los querys o algo mas ?

Por lo que parece lo mejor sera usar dialecto 3 verdad?

Gracias por su aporte

Yo me encontre con los siguientes problemas comunes:

1) En dialecto 3 no debes usar comillas dobles (") para especificar un String, si no que debes usar comillas simples(').

2) Si en una consulta declaras un Alias, lo mejor será que lo uses, osea... si haces esto:

Código SQL [-]
select c.nombre, sucursal.telefono from cliente c, sucursal s where s.id=c.id

Seguramente te dira que el campo telefono no existe ya que el alias es s no sucursal.

3) No debe repetir los campos en las insercciones, osea:
Si en alguna parte haces algo como...

Código SQL [-]
insert into cliente(nombre, apellido, nombre) values('pepito', 'perez', 'pepito');

Te dira que estas redeclarando un campo en dicha consulta.

4) Si en Dialecto 1, tenias campos tipo Date donde guardabas la fecha y la hora, En Dialecto3 tendras que redeclararlos como TimeStamp, ya que el Date en Dialecto3 solo guarda la fecha y el Time la Hora, mientras que el TimeStamp guarda los dos valores como lo hacia el Dialecto1.


Bueno, esas son las cosas de las que me acuerdo hasta ahora, si me acuerdo de alguna otra mas adelante la anexare a la lista :).

una inquietud... entonces me imagino que es recomendable asignar los valores de la siguiente forma??:

Código Delphi [-]
    QConsulta.FieldByName('campo_doble').AsBCD := varFlotante;

y no así:

Código Delphi [-]
    QConsulta.FieldByName('campo_doble').AsFloat := varFlotante;

No serviría de nada. No se perdería definición en Delphi, pero al guardar en la base de datos, es cuando se produce el fallo (porque es inherente al tipo de datos double precision o Float en dialecto 1).

Bien es verdad, que teniendo un campo definido como Float y usando siempre .AsCurrency (tanto para mostrar como para asignar un valor al campo) estamos minimizando el problema. Queremos guardar el valor 23.30:

Código Delphi [-]
campo.AsCurrency := 23.30;
// en la base de datos quedará como 23.29999999   (un suponer)
tabla.post
ShowMesage(FloatToStr(campo.AsCurrency));
// al leer como Currency, normalmente se hace un redondeo y mostrará 23.30

El problema añadido, es que al utilizar ese valor en operaciones matemáticas los errores de decimales se van acumulando.

Saludos

Al parecer este hilo puede llevar a confusiones al que busca en los foros.

En resumen: El problema es del tipo double precision y Float en todas las bases de datos.

Aunque como ya se ha visto en Firebird y Dialecto 3 se ha resuelto el problema.

Saludos

Resp
 

No queria opinar este hilo pero tengo que hacerlo.

Mira cual como se deberia llamr este hilo.

Yo no se usar firebird. Y por eso digo que no es seria.

Ven que asi se ve mejor.

Se supone que oaracle es un manejador de base de datos y me toco auditar un sistema con una base de datos que no orecle la podia soportar de lo mal diseñada que estaba. Eso tiraba errores por todoss las lados las mismas consultas devolbian valores diferentes y mucas cosas mas(Usaron una sola tabla para realizar un registro de personas con sus familiares nacionalidades y otro nmonto de datos mas).

Tabien sabian que c es el lenguaje mas potente que existe. pero he visto unas poruqerias de aplciaciones echas con c.

El titulo que sugeri antes tanpoco esta bien es un poco despota.
Pero este si.
Cuando el panadero es malo le echa la culpa a la harina.

Ese si esta bello.

:D:D:D, según quien.........

Salud OS

resp
 

Segun nadie.