Yo estuve leyendo sobre los tipos de datos en SQLite, y veo que SQLite es bastante especial en este sentido. Como dice Agustín, los tipos se dan por afinidad... una especie de "compatibilidad" y que SQLite trata de imitar y de convertir.
Técnicamente el tipo FLOAT(3,2) como lo tienes no existe. SQLite, si es que estoy entendiendo bien, lo que trata de hacer es tomar lo que le pases y asumir a ese FLOAT() como quizá un REAL o un INTEGER.
Luego, desde Lazarus estás asumiendo que es equivalente a un tipo flotante (para ser concreto Double) y cuando haces el paso desde Lazarus hacia la base de datos, es posible que ahí es cuando se rompen las afinidades...
Lo mejor sería respetar los propios tipos de datos que ofrece SQLite.
Cuando se trabaja con valores que serán usados con fines monetarios, desde el lado del sistema, lo más adecuado es valerse del tipo Currency. Que es un tipo bastante especial. Técnicamente es un entero, pero que se comporta como un tipo real con punto fijo (4 decimales para ser exactos, aunque visualmente como sabemos sólo son usados 2). Esto permite realizar operaciones con exactitud. ¿Porqué 4 decimales? Para que cuando uno haga divisiones entre dos currency tener el valor exacto (un número de 2 decimales dividido por otro de 2 da como resultado uno de 4). Internamente el compilador va a multiplicar o dividir por 1000 cuando sea necesario para "correr la coma".
Por ello, si se emplea campos persistentes, al campo que representa este valor monetario (Zeos genera un TFloatField) lo mejor es establecerle la propiedad Currency en true para forzar a que internamente use Currency y no el Double.
Ahora bien, hay que encontrar el tipo más conveniente equivalente al Currency para SQLite. Al menos en Firebird tradicionalmente se emplea NUMERIC(12, 2), pero en SQLite no existe el NUMERIC(), aunque tiene afinidad hacia éste. De lo que leo, primero intentará convertirlo al INTEGER y luego al REAL. En Firebird internamente un NUMERIC(d,p) es un tipo entero y aplica aritmética fija como lo que hace el Currency de Delphi y Lazarus. Ahora bien, dependiendo de la cantidad de dígitos (d) reservará un entero de 16 o 32 bits. En SQLite por lo que leo, el integer es mucho más abierto y puede ser de 1, 2, 4, 6 y 8 bytes a nivel de disco... e internamente en memoria ram todo parece traducirse en un Int64 (o lo que es lo mismo, en 8 bytes)
¡Lo peor es que esto de la afinidad hace que sea tan ambiguo porque incluso hasta pareciera permitirle pasarle texto! Y dejar que el "motor" haga el trabajo de conversión. Eso es al menos lo que yo entiendo.
Esto a mi me confunde, y por ello no me animé a comentar antes. 
Me siento perdido, ¿Al final como es conveniente hacer la equivalencia entre el Currency de Delphi y Lazarus y SQLite? ¿usar INTEGER? ¿TEXT? Arrojen luz porque estoy ciego.
Saludos,
