[Lazarus-es] Firebird zeos INSERT INTO no funciona

[Jose Antonio. Cuello Principal]

Hola, hace muchísimo que no uso TTables. Solo uso TZQuery, a veces enlazado con un TZUpdateSQL. Y a transacción, una sola. Es decir no hacía commit por tabla o por insert. 
Cuando digo tabla, me refería a la base de datos. 


No creo que fuese eso, pero gracias por la sugerencia. 
Un saludo 

----- Mensaje original -----

De: "Maxi" <maximiliano.duarte en gmail.com> 
Para: "Spanish version of Lazarus List" <lazarus-es en lists.lazarus.freepascal.org> 
Enviados: Miércoles, 10 de Octubre 2012 22:39:49 
Asunto: Re: [Lazarus-es] Firebird zeos INSERT INTO no funciona 

El día 10 de octubre de 2012 06:02, Jose Antonio. Cuello Principal 
<jcuello en artextrading.com> escribió: 
> Hola, los componentes eran Zeos (no recuerdo la versión) con conexión a 
> firebird y entorno Delphi (5 ó 6) 
> 
> La pantalla no tenía mucha cosas, un progresbar era lo único que requería 
> refresco. 
> 
> y las tablas (entre 8 y 10) tenían bastantes registros pq contenían u 
> historico de 3 ó 4 años. 
> Siento no ser más claro, pero hace ya unos añitos del tema. 
> Gracias, por tus respuestas. 
> Un saludo 
> 
> ________________________________ 
> De: "José Mejuto" <joshyfun en gmail.com> 
> Para: "Spanish version of Lazarus List" 
> <lazarus-es en lists.lazarus.freepascal.org> 
> Enviados: Miércoles, 10 de Octubre 2012 9:40:46 
> 
> Asunto: Re: [Lazarus-es] Firebird zeos INSERT INTO no funciona 
> 
> El 10/10/2012 9:13, Jose Antonio. Cuello Principal escribió: 
> 
>> Siguiendo con este tema, siempre sospeche que el problema eran los 
>> numerosos parambyname que se ejecutaban durante el proceso. Es decir, 
>> que no era un problema de base de datos sino del proceso a la hora de 
>> traspasar los datos. El caso es que mi supervisor de entonces no me dejó 
>> hacer pruebas y me lo hizo cambiar, luego pase a otras cosas y ahí quedo 
>> el tema. 
>> Es posible que al tener que hacer ejecutar muchos ParambyName (entre 10 
>> o 15 no recuerdo exactamente cuantos eran) por cada insert hacían que el 
>> proceso tardara más que si montabas un string con la sentencia. 
>> 
> 
> Hola, 
> 
> No lo creo, veo más posible algún tipo de bug en los componentes que el 
> propio hecho de pasar parámetros "byName". Aunque los "byName" son 
> costosos, son locales y lo más lento debería ser en envio/recepción de 
> datos al hacer los prepare. Puede darse el hecho de que un bug realizara 
> el prepare cada vez que se ejecutaba el SQL aunque este no se hubiera 
> modificado, por lo tanto tendríamos la carga normal del prepare y 
> añadidos todos los "byName" aunque multiplicar por 4 el tiempo de 
> proceso me parece excesivo. 
> 
> Sería interesante hacer algunas pruebas... Si tengo un rato haré un test 
> con una BD. 
> 
> 
> 
> _______________________________________________ 
> Lazarus-es mailing list 
> Lazarus-es en lists.lazarus.freepascal.org 
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus-es 
> 
> 
> _______________________________________________ 
> Lazarus-es mailing list 
> Lazarus-es en lists.lazarus.freepascal.org 
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus-es 
> 


Ahi esta el tema del tiempo, el objeto ttable para motores sql no 
estaba aconsejado, incluso hoy tampoco lo aconsejan, porque esta por 
compatibilidad. 
el TTable trae a memoria casi toda la tabla y no es eficiente en las 
actualizaciones, siempre en un entorno cliente servidor es mejor usar 
Querys 

-- 
El que pregunta aprende, y el que contesta aprende a responder. 

No a la obsolecencia programada: 
http://dimensionargentina.blogspot.com/2011/01/todo-esta-disenado-para-romperse.html 

Linux User #495070 
http://domonetic.com/blog 

_______________________________________________ 
Lazarus-es mailing list 
Lazarus-es en lists.lazarus.freepascal.org 
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus-es 

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus-es/attachments/20121011/27f01ca7/attachment-0002.html>