Pues ya me queda más claro que el fichero no inserta solamente los campos, sino la estructura de la tabla y contenido interno.
Como digo, el error que me "saltaba" era "SQL ERROR: SQL LOGIC. ERROR OR MISSING DATABASE. Aceptar o Continuar...."
Procedí como digo a cambiar nombre VARCHAR(30) como indica enecumene a (nombre TEXT), idem lo mismo con edad y voilá funcionaba y ese error me dejo de salir.
Ahora he vuelto a cambiarlo, porque así lo tienes en la "demo" y ya sin explicación alguna FUNCIONA!!! cuando antes no funcionaba?. No tengo explicación a esto Delphius, como digo he cambiado la declaración del tipo de campo simplemente. El schema siguen estando en todos los casos.
Ahora a continuar, veré tu demo a fondo Delphius, y complementaré con el codigo de enecumene que voy entendiendo. Me queda hacer una consulta a la tabla y volcar los datos del fichero "main.db" al DBGRID, pero enecumene no hace mención al
DATASOURCE por ninguna parte.
Una sola cuestión, como se reemplazar el INSERT por el codigo adjunto? que habría que eliminar para usarlo?
Desearía seguir viendo la claridad, pero estoy convencido que volverán las sombras...
Saludos y mil gracias! No me cansaré de darlas!
No estoy a tu lado dooper asi que no te sabría decir porque el cambio de tipo antes no te resultó y después si, si estabas manteniendo el schema. Quizá el archivo estaba ya corrupto después de varios cambios, idas y vueltas, y tras algún borrado se arregló. Pero sólo estoy suponiendo.
Enecumene no habló de DataSource en ningún momento puesto que su ejemplo sólo se limitó a comentar como se carga dinámicamente y en ejecución la biblioteca de SQLite y en como proceder a insertar. El DataSource sólo tiene sentido cuando va a plantearse el uso de controles data-ware como DBGrid, DBEdit, DBNavigator, entre otros.
Uno puede prescindir de un TDataSource, no es obligación usarlos. El TDataSource lo único que hace es hacer de "puente" entre los controles data-ware y los DataSets (Querys, Tables, StoreProc, etc). Claro esta, que el no usarlos implica un costo más para el programador ya que ahora es su responsabilidad en traer los datos y encargarse de leer y recorrer el conjunto para mostrarlos en un StringGrid tradicional por ejemplo. Algo como esto:
zquery1.First; // me voy al primer registro
i := 0;
while not zquery1.EOF do // mientras no haya llegado al último registro...
begin
i := i + 1;
stringGrid1.RowCount := i; // incremento las filas del grid
stringGrid1.Cells[1, i] := zquery1.FieldByName('Nombre').AsString; // a la fila i-esima le paso el dato
zquery1.Next; // me voy al siguiente registro
end;
Y cosas análogas a esas para hacer el paso inverso: desde los controles no-data-ware hacia el/los DataSets que necesite.
Hay dos corrientes en el mundo de Delphi y Lazarus: los que usan mucho data-ware y los que prefieren evitarlos. Motivos de pros y contras para cada una los hay. Por el lado del NO uno de sus razones es que un error de configuración y/o de mal control de las operaciones que se van a realizar puede provocar que un control data-ware envíe la orden de realizar una inserción o de entrar en modo edición ¡O un borrado! cuando no estaba previsto eso. Es muy fácil disponer de controles data-ware, unos datasource, vincularlos con los datasets y con prácticamente nada de código tener un ABM. Es muy bueno eso. Nos ahorra mucho trabajo duro, es rápido, intuitivo.
Pero ahora multiplica un ABM diseñado para una tabla sobre un diseño de un sistema que maneja una base de datos de 50 tablas, con 25 formularios del tipo ABM... y ¡trata de no meter la pata como dejarte abierta una tabla o un DataSource vinculado a dos forms!
En cierto modo el concepto de data-ware escapa a ciertos conceptos de la POO y de algunas Buenas Prácticas, y es aquí donde los más extremistas del "grupo NO" y puristas del POO ponen más fuerza. Cuando una aplicación se concibe bajo el patrón Layers (Capas en español) y empieza a concebir capas como Aplicación, Presentación y Dominio como que el enfoque data-ware les resulta más una "incomodidad" y prefieren tener absoluto control de cuando y como leer y escribir en y desde sus DataSets ¡Por sus propios medios! ¡Y hasta se plantea la posibilidad de definir o usar un framework de persistencia!
Pero no sigo más porque esto es ya un tema más "avanzado" y te voy a hacer lios.
Tu continúa practicando. Ya verás que las cosas se te van a ir dando paso a paso. Y naturalmente llegará el momento en que te plantearás el debate de si usar o no data-ware... Sobre todo si te enamoras del purismo OO. Como algunos (yo me incluyo) 
Saludos,
