Ir al contenido



Foto

Problema con campos TBCDField


  • Por favor identifícate para responder
11 respuestas en este tema

#1 razadi

razadi

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 681 mensajes
  • LocationMéxico D.F.

Escrito 24 noviembre 2017 - 02:17

Pues eso srs. alguien sabe porque sólo me deja captura 4 dígitos en un DBEdit un campo TBCDField?

 

Estoy conectándome a una base de datos MySQL en la tabla el campo es DECIMAL(15,4) cuando relaciono este campo con un TFDQuery (FireData) y agrego los campos los decimales me los pone como BCD y al momento de capturar sólo puedo poner 4 números y no le eh puesto formato de captura ni nada.

 

Alguien con el mismo problema que lo haya resuelto o sepa de esto??

 

 

de antemano gracias y saludos.

 

*-)  *-)  *-)


  • 0

#2 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 803 mensajes
  • LocationArgentina

Escrito 25 noviembre 2017 - 02:09

Creo que firedac, en las propiedades de la conexión, te permite especificar una serie de reglas de mapeo, de cómo debe interpretar los campos. No recuerdo exactamente el nombre del parámetro, pero lo podes buscar en tiempo de diseño. En tu caso creo que lo mejor es decirle que lo tome como un Currency

También se que fue mencionado y mostrada ésta característica en un vídeo en YouTube el cual trataba sobre migraciones desde componentes de acceso a datos obsoletos a firedac. Si lo encuentro lo publico
  • 1

#3 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 01 diciembre 2017 - 08:14

Hola.

 

¿ Cuando dices que solo te deja poner 4 dígitos, te refieres a la parte decimal o en total ?. Porque si solo te deja poner 4 en la parte decimal, será porque decimal(15,4) solo puede contener 4 dígitos decimales. En todo caso, cambia el valor de la propiedad Size en el campo persistente, para cambiar el nº de dígitos decimales con los que quieres trabajar (pero recuerda que en cualquier caso, la base de datos solo guardará cuatro).


  • 0

#4 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.009 mensajes
  • LocationArgentina

Escrito 01 diciembre 2017 - 10:24

Efectivamente, cuando define tanto un DECIMAL como NUMERIC con la dupla (a,b) le está indicando que el número en cuestión tenga a digitos en total y de éstos b corresponderán a la parte decimal.

 

Además déjame decirte que la idea de los campos BCD y/o currency es usarlos para fines monetarios, para ello fueron pensados. Y como tal, no TIENE SENTIDO poner más de 4 decimales.

No hay país en el mundo que maneje una moneda menor al céntimo (2 decimales). E incluso hay países en los que NO usan decimales, como ser Chile cuya moneda son números enteros.

 

Los 2 decimales más bajos están como dígito de guarda para que las operaciones de división y multiplicación se hagan de forma precisa (multipliquen dos números con 2 decimales y vean que obtienen... a ver si me explico  ;)  )

 

Saludos,


  • 2

#5 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 13.690 mensajes
  • LocationMéxico

Escrito 01 diciembre 2017 - 11:26

Efectivamente, cuando define tanto un DECIMAL como NUMERIC con la dupla (a,b) le está indicando que el número en cuestión tenga a digitos en total y de éstos b corresponderán a la parte decimal.

 

Además déjame decirte que la idea de los campos BCD y/o currency es usarlos para fines monetarios, para ello fueron pensados. Y como tal, no TIENE SENTIDO poner más de 4 decimales.

No hay país en el mundo que maneje una moneda menor al céntimo (2 decimales). E incluso hay países en los que NO usan decimales, como ser Chile cuya moneda son números enteros.

 

Los 2 decimales más bajos están como dígito de guarda para que las operaciones de división y multiplicación se hagan de forma precisa (multipliquen dos números con 2 decimales y vean que obtienen... a ver si me explico  ;)  )

 

Saludos,

 

Bueno, acá en México utilizamos hasta 6 decimales en la paridad  Peso-Dolar, aunque normalmente se muestra con 4 decimales, hoy lo tenemos en 18.5190 y Mañana estará en 18.6229 pesos por cada dolar.

 

Saludos


  • 1

#6 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.009 mensajes
  • LocationArgentina

Escrito 01 diciembre 2017 - 11:55

Bueno, acá en México utilizamos hasta 6 decimales en la paridad  Peso-Dolar, aunque normalmente se muestra con 4 decimales, hoy lo tenemos en 18.5190 y Mañana estará en 18.6229 pesos por cada dolar.

 

Saludos

 

Eso es distinto amigo. Esos decimales son necesarios para obtener la precisión necesaria al realizar la conversión de una moneda a otra y aplica al área de Finanzas y el Comercio en Bolsa. De todas formas, al final, se hace un redondeo a los 2 decimales cuando uno va a las casas de cambio.

 

De todas formas no invalida lo que he dicho yo: NO hay país que tenga moneda menor al céntimo. Vayan a cualquier rinconcito del planeta y pidan que le den un vuelto menor al céntimo a ver si consiguen esos milésimos ;)

¿O acaso pueden comprar algo menor al centavo? No. No pueden. No pueden hacerlo en Afganistan, ni en Suecia, o en Canadá o en donde se les ocurra.

 

En mi país incluso, la ley es muy clara en ese punto: todo cálculo menor al centavo debe ser redondeado a éste. Tenemos otra más, llamada Ley de Lealtad Comercial que estipula que cuando la diferencia no supere a los 5 centavos y no sea posible efectuar el cambio la diferencia sea a favor del cliente. Algo ya bastanta obsoleta porque hace años que no se ve monedas de 5 ni de 1 centavos. Hay un proyecto para llevarlo al peso... y hay otros que piden que sea llevado a los $2 ya que hasta las de $1 son escasas igual que los billetes de 2.

 

Saludos,


  • 2

#7 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 13.690 mensajes
  • LocationMéxico

Escrito 01 diciembre 2017 - 12:15

Eso es distinto amigo. Esos decimales son necesarios para obtener la precisión necesaria al realizar la conversión de una moneda a otra y aplica al área de Finanzas y el Comercio en Bolsa. De todas formas, al final, se hace un redondeo a los 2 decimales cuando uno va a las casas de cambio.

 

De todas formas no invalida lo que he dicho yo: NO hay país que tenga moneda menor al céntimo. Vayan a cualquier rinconcito del planeta y pidan que le den un vuelto menor al céntimo a ver si consiguen esos milésimos ;)

¿O acaso pueden comprar algo menor al centavo? No. No pueden. No pueden hacerlo en Afganistan, ni en Suecia, o en Canadá o en donde se les ocurra.

 

En mi país incluso, la ley es muy clara en ese punto: todo cálculo menor al centavo debe ser redondeado a éste. Tenemos otra más, llamada Ley de Lealtad Comercial que estipula que cuando la diferencia no supere a los 5 centavos y no sea posible efectuar el cambio la diferencia sea a favor del cliente. Algo ya bastanta obsoleta porque hace años que no se ve monedas de 5 ni de 1 centavos. Hay un proyecto para llevarlo al peso... y hay otros que piden que sea llevado a los $2 ya que hasta las de $1 son escasas igual que los billetes de 2.

 

Saludos,

 

Si, si, en la práctica no es visible mas de 2 digitos decimales, pero estamos hablando de cálculos internos donde se requiere de contar con mas de esas dos cifras, y bueno todo depende de cada país, hay algunos (como el nuestro) que eso de los redondeos es un tema muy complejo.

 

 

Saludos


  • 0

#8 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.009 mensajes
  • LocationArgentina

Escrito 01 diciembre 2017 - 12:44

Pues a menos que estés pensando en Finanzas y en la Bolsa de Comercio no tiene sentido ir por más de 4 decimales.

No es necesario ya que con 4 obtendrás para llevar la precisión de los cálculos internos para que al mostrar los resultados tengas exactitud.

 

Es más tengo mis dudas si Delphi te permite trabajar con un DECIMAL(17,6) (por dar un ejemplo) y que internamente sea un BCD o un Currency. A nivel DB podrás ponerle los digitos que requieras (aunque lo máximo posible es usar lo equivalente a un INT64) pero en Delphi el BCDField  puede que no que acepte eso.

 

Que yo recuerde el BCDField tiene una propiedad que le permite definir como interpretar internamente el número. Si usa un Currency, Float, o el tipo TBCD que es un tipo record bastante peculiar y se le conoce tener sus cosillas (como ésta que en su momento traté en CD)

 

Si al BCDField se lo tiene configurado para que use Currency le dará la mismo que pases 5 o más decimales... se los pasará por los huevos y el número se verá redondeado a 4 decimales. Currency sólo acepta 4.

Si está en "modo float" bueno, la cosa ya cambia.

 

Saludos,


  • 0

#9 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 13.690 mensajes
  • LocationMéxico

Escrito 01 diciembre 2017 - 12:48

Pues a menos que estés pensando en Finanzas y en la Bolsa de Comercio no tiene sentido ir por más de 4 decimales.......

 

Saludos,

 

 

Es mi caso amigo :) son sistemas de comercio exterior. De Razadi no sé, pero asumo que tiene un problema similar.

 

Saludos


  • 0

#10 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 13.690 mensajes
  • LocationMéxico

Escrito 01 diciembre 2017 - 12:51

Y si, el tipo Currency es lo mejor cuando se habla de cálculos de aplicaciones punto de venta y contabilidad :)

 

Saludos


  • 1

#11 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.009 mensajes
  • LocationArgentina

Escrito 01 diciembre 2017 - 01:10

Es mi caso amigo :) son sistemas de comercio exterior. De Razadi no sé, pero asumo que tiene un problema similar.

 

Saludos

 

Ummm. Podría hacer alguna prueba con Zeos + Firebird a ver que tipo de Field me genera por defecto si hago un tipo DECIMAL(n,6). En lo primero que pienso es que me generaría un TFloatField, pero no estoy completamente seguro.

La cosa es que si genera cualquier tipo de coma flotante que no sea de punto fijo se estará tentando a la posibilidad de que se pierda precisión en el último digito y te tire todo al cuete cuando veas que no te cierran las cajas por esa eterna lucha del centavo faltante.

 

Y si, el tipo Currency es lo mejor cuando se habla de cálculos de aplicaciones punto de venta y contabilidad :)

 

Saludos

 

Y si. Para eso fue pensado y diseñado.

 

Ahora otra forma de encarar la cosa es como ya una vez sugerí en el foro: emplear aritmética entera y simular lo que ya hace Currency. En lugar de pretender guardar números con los decimales corremos la coma y guardamos enteros. En lugar de 1234,5678 guardamos 1234578. Y en lugar de sumar 9876,1234 + 4321,6789 sumamos 98761234 + 43216789.

 

Al momento de mostrar (y nunca antes, y por sobre todo en operaciones intermedias) aprovechamos a presentarlo formateado a 2  o 4 decimales.

 

Esta misma técnica es válida para cualquier cantidad de decimales. Es lo lindo de la matemática entera. No perdemos ningún centavo, ni montos inferiores. Ahora eso si, todo tiene límite: el máximo número que puede meterse en un entero de 32bits o en uno de 64bits (aunque vaya a a encontrar al loco que tenga semejante fortuna) y debe cuidarse del tema si de admitiremos o no números negativos (es un bit menos con que podríamos contar... ojo no desprecien)

 

En algún lado había leído sobre algo llamado Principios Aceptados de Contabilidad o algo por el estilo y había ciertas "normas" que debían seguirse para hacer un buen sistema. Una de esas cosas mencionaba la posibilidad de valerse de aritmética entera y evitar tipos de coma flotante. He intentado encontrar ese documento de nuevo en los últimos meses sin resultado ya que me interesa en sobre manera aprender bien eso.

 

Saludos,


  • 0

#12 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.009 mensajes
  • LocationArgentina

Escrito 01 diciembre 2017 - 01:48

Pues acabo de hacer una prueba, tanto con un DECIMAL(17, 6) como un (15,6) Zeos me genera de forma persistente un TExtendedField.

Y este no es más que una encapsulación de un double.

Como era de sospechar, si usas 6 decimales... piensa en double.

No es pecado usar double, tiene buena precisión y sirve para muchas operaciones de ingeniería. Ahora como he recalcado muchas veces cuando sale el temita de los números flotantes... hay que aprender a usarlos ;)

 

No creo que sea tan diferente el resultado con otra suite. Lo más probable es que con cualquiera al leer el ,6 ya te tire para un tipo double (o quizá el float pero es poco probable) por defecto. A menos que forcemos a usar un field en concreto...

 

Lamentablemente no puedo hacer una prueba para el caso de Razadi ya que no cuento con esa suite.

 

EDITO:
Y en Lazarus, Zeos me genera un TFloatField, que es casi lo mismo (por no decir lo mismo).

 

Saludos,


  • 0