Lazarus, Linux, ZeosLib, Firebird. ¿Qué combinación funciona?
 

Hola,

Hemos tratado de usar los componentes ZeosDB 6.6.6 en Lazarus para conectar con Firebird, bajo Linux Ubuntu, y aunque logramos conectarnos, de ahí no pasamos. El más elemental SELECT * FROM TABLA no trabaja; falla al intentar poner el Active a TRUE

Inicialmente, por datos de internet, pensamos que era problema de instalación, o de versión y probamos varias combinaciones, hasta que terminamos dañando nuestra instalación. Antes de reinstalar todo, investigamos un poco más y hemos encontrado una información preocupante.

Al parecer, las construcciones del cliente Firebird posteriores a la 13130 tienen incompatibilidad con ZeosDBO. Alguién puede confirmarlo ?

Ahora, si eso es así, tenemos un problema mayor porque, a partir de la versión 2.0, todas las construcciones de las versiones vigentes que están disponibles actualmente para descarga, y que hemos encontrado, son posteriores a esa construcción.

Alguién puede indicarnos cuales de la versiones vigentes trabajan con Zeos y donde conseguír una construcción que funcione de esas versiones ?.

Ahora, independientemente de eso, si efectivamente hay un problema de esa magnitud, ello nos obliga a reconsiderar Zeos como la herramienta adecuada para nuestras conexiones.

Nosotros debemos trabajar con una herramienta que permita seleccionar el motor de Base de Datos a tiempo de ejecución. Que nos sugieren ?

¿Dónde has leído eso?, pon el enlace. A mí me funciona normalmente con fb1.5
¿A qué te refiieres con las construcciones del cliente Firebird posteriores a la 13130?

Prueba con fb1.5, lazarus, ubuntu y zeoslib:

Más detalles del caso
 

Hola CasimiroNotevi,

Muchas gracias por contestar. El dato lo ví en más de una página. Aquí hay una de ellas:

http://www.forolazarus.com/phpBB3/viewtopic.php?f=4&t=7

Tú estás usando la versión 1.5; pero, esa versión está descontinuada. Mira esta página:

http://www.firebirdsql.org/en/firebird-1-5/

La versión 1.5 es muy vieja con respecto a las versiones actualmente vigentes. Si bien a modo de prueba puedo instalarla, el caso es que estaría en el mismo dilema que con el BDE. El BDE a mi siempre me ha funcionado muy bien e incluso aún tengo aplicaciones usándolo; pero, tuve que migrar a dbExpress porque el BDE fué descontinuado. Ten en cuenta que mi aplicación no es para una empresa en particula y en tal caso, restricciones de esa índole no tienen presentación.

Nosotros somos nuevos en esto de Linux. Lo hacemos porque toda la referencia que tenemos lo señalan como un servidor superior a Windows. Nuestras aplicaciones normalmente no tendrán problemas con Windows; pero, en caso extremo, el costo se incrementaría tanto por Licensias como por la necesidad de hardware más robusto. Linux es una alternativa atractiva.

Elegimos Lazarus por su facildad para migrar desde Delphi; pero, me preocupa que desde un principio nos ha dado muchos problemas.

Eso es fundamentalmente por la escasez de documentación y de personas conocedoras a fondo del tema; lo que nos ha obligado a perder mucho tiempo resolviendo casi todos los problemas por nosotros mismos, a base de seguimiento de un código de terceros. Eso es muy satisfactorio profesionalmente; pero, no es productivo.

Bien entendido, solo planeamos usar Linux/Lazarus para nuestro servidor Web. Los clientes seguirán en Delphi bajo Windows; dado que en nuestro medio casi nadie usa Linux como cliente, así que no vale la pena el esfuerzo de migrar la parte cliente; no nos aporta ningún valor agregado y seguramente si nos daría muchos dolores de cabeza. Empezando porque hasta donde hemos visto no se cuenta con capacidades de depuración del nivel que tenemos en Delphi; pero, eso es otro tema.

En ese orden de ideas, los componentes que realmente nos interesan son únicamente los de FPWeb y los de acceso a Bases de Datos; y quizás alguno que otro más.

Agradeceríamos mucho las orientaciones que nos den al respecto

Si lo que quieres es usar Zeos con FB 2.5 pues dilo de manera mas especifica en vez de tanta cháchara xD, ZEOS 7 funciona con FB 2.5, ya lo he probado.

Gracias. Comentarios
 

Hola mightydragonlor,

Muchas gracias por aportar.

Intentamos usar Zeos 7.0.1; pero. no compiló. La versión 7.0.0 si compiló; pero; nos sacó un error. Sin embargo, con tantas pruebas e instalación de versiones es probable que el sistema ya esté muy dañado, y es posible que haya sido por eso. Estamos re-instalando absolutamente todo, empezando por Ubuntu 11.04 Naty. Creo que ya mañana podré comentar con más certeza.

Mil disculpas si te parece que escribo mucho. Es tú modo de pensar y lo respeto; pero, yo soy de los que piensa que hay que explicar bien las cosas para que se entiendan. Las frases escuetas a menudo dan información incompleta y generan malos entendidos. Yo procuro dejar las cosas en contexto por aquello de que no hagas con otros lo que no quieras que hagan contigo. No malinterpretes, no es ironía ni doble sentido; solo explico mi modo de expresarme

Hola Rolando, recuerda que las letras xD denotan que es una charla, muy usadas en los chats que no tienen emoticones y mas faciles que buscar la carita pa seleccionarla =P, un saludo.
PD. la versión de Zeos con que me funciona es 7.0.0-dev, de todas formas danos el error o la lista de errores específicos que te arroje el depurador, así podremos encontrar mas fácilmente el error, lo mismo versión de lazarus.

Ningún linux se daña por instalar los componentes zeos varias veces :), ni aunque instales y desinstales mil programas mil veces.
En mi trabajo se montan sólo servidores linux, desde hace ya 11 años y salvo por avería física del disco duro, nunca jamás hemos tenido que reinstalar un linux en todo ese tiempo. Empezamos montando redhat, luego suse, luego debian, luego ubuntu y ahora se monta indistintamente suse y ubuntu, según las preferencias de cada uno. Pues ni los que se instalaron hace 11 años se han reinstalado todavía, siguen tal y como se pusieron en su día, lo que sí se ha cambiado ha sido la versión de firebird, las actualizaciones de seguridad que hayan sacado, etc.

"nos sacó un error", ¿y qué error?, ¿no sería más fácil investigar para solucionar ese error que reinstalar linux?, es que me recuerda al típico usuario novato en windows, que le sale una pantallita de error de cualquier cosa y formatean el equipo y reinstalan windows, cuando quizás el mensaje era: "dentro de 30 días caduca la versión de prueba del visor de pdf".

Otra cosa, hablas de la versión 7.0.1, de la versión 7.0.0, etc. para trabajar se debe usar una versión estable bien probada, y si la última estable y bien probada, que se sabe que funciona perfectamente es la 6.6.6 (que no lo sé, es por decir algo), pues entonces hay que instalar esa, la 6.6.6
En mi trabajo casi todos los clientes siguen con firebird 1.5 y sólo últimamente se está empezando a instalar la 2.1, sin embargo todavía no tenemos pensamiento de instalar la 2.5 en ningún sitio.

Bueno, ya no sigo más, me voy a desayunar :)

Hola Casimiro, te recuerdo que Zeos 6.6.6 no funciona con Firebird 2.5, supongo que las llamadas al cliente habrán cambiado, pero la verdad es que falla no en la conexión en si, sino cuando ejecutas un zQuery o usas un zTable, entonces si lo que quiere es usar el 2.1 con Zeos 6.6.6 pos con ese si funciona =),
saludos.

¿En serio?, no entiendo el motivo, si son muy similares :confused:
¡¡¡Ufff!!!, si eso es así, no sé, hay algo extraño, tendría que informarme mejor sobre zeoslib, pero en principio me hace dudar bastante sobre su uso con firebird, puede que esté más "afinado" para otras bases de datos.

Pos la verdad a mi también me decepcionó un poco, pero puedes hacer la prueba tu mismo, seguro que encuentras el por que ^^, S4lu2.

Pues si eso es así, ha disminuido mucho mi interés por zeos.
Habrá que hacer un poco de tiempo para probarlo.

Reportandome
 

Hola,

Disculpen la demora. Tuvimos inconvenientes externos y no pudimos trabajar en este problema. Ya será el Lúnes

De todas formas, aclaro algunos puntos:

1. El mensaje se refería a que una operación forward no era permitida. Ocurría al poner Active en True en un TZReadOnlyQuery

2. Al parecer, en algún punto se mezclaban versiones por nombres de archivos idénticos. Creemos que eso podía ser lo que dañara las compilaciones porque uno esperaría que un paquete de estos al menos compilara.

3. Nosotros intentamos desinstalarlos; pero, hasta donde vimos en Lazarus tan solo se retiran los paquetes de la lista de instalados; no se borran los archivos compilados ni el camino a ellos. Los paquetes de las versiones aparentemente usan el mismo camino, así que se mezclaban.

4. Tratamos de desintalarlos completamente con unas instrucciones que hallamos (purge y algo más que no recuerdo ahora). Tampoco funcionó, así que optamos por borrar los archivos previamente compilados. Y creímos que lo habíamos hecho bien porque ahí compiló la 7.0.0, y nuestra aplicación de prueba; pero, la próxima vez que arrancamos el sistema, Lazarus sacaba errores

5. Nosotros si intentamos resolverlo primero investigando; pero, después de un tiempo prudencial concluímos que era más rápido volver a instalar todo. Entre otras cosas porque aparte del Ubuntu solo habíamos instalado lazarus, zeos, firebird y apache; reinstalar no es muy demorado, además nos sirve para practicar y verificar la documentación que hicimos de nuestra experiencia instalando y configurando. Recuerden que somos novatos en Linux.

6.

Gracias por las explicaciones :)

Una pregunta complementaria
 

Hola,

No hay de que. Es que hay mucho que aclarar. Por ejemplo, faltó algo que implica una pregunta complementaria.

Nos solicitaron que indicaramos lo que arroja el depurador. Como lo usamos ?.

Nosotros lo que hicimos fué poner mensajes de seguimiento porque no encontramos un depurador incorporado. Según leímos hay herramientas externas, caso GDB; pero, no con la facilidad de depuración que tenemos en Delphi, la cual, incluso con los ISAPI, que se corren con una herramienta externa a Delphi, nos permite depurar en ejecución línea a línea y viendo las variables de entorno.

Aquí parece que hay que esperar a un texto resultante y las cosas se revisan usando comandos. Además, por lo que vimos dentro del código de los paquetes de fpweb (nuestro problema anterior, descrito en este hilo http://www.clubdelphi.com/foros/showthread.php?t=75517) parece que hay que mezclar en nuestro código instrucciones para la depuración.

Toda esa información es correcta ?. O hay ya alguna manera cómoda de depurar ?

A propósito de eso, y lo dicho por mightydragonlor acerca de encontrar las cosas por uno mismo, comento lo siguiente:

A nosotros también nos gusta hacerlo. Son múltiples los casos que hemos resuelto así. De hecho, el problema anterior que menciono lo resolvimos revisando el código fuente de esos componentes; pero, no tenemos el tiempo disponible (habrá que esperar a la jubilación je! je!). Lo podemos manejar mientras sean situaciones aisladas y esa es la ventaja de tener los códigos fuente; pero, aquí preocupa mucho que las fallas sean desde lo más elemental.

Un buen depurador es algo que todavía está pendiente, el GDB funciona bien, aunque he oído comentarios de que a algunos no les funciona como debería, en las pruebas que he hecho yo, la verdad, va bastante bien. Aunque también es cierto que no hay comparación con el de delphi.

Triste confirmación; pero, muchas gracias
 

Hola,

Muchas gracias por la información.

Eso confirma lo que, en base a lo hasta ahora leído, nos temíamos.

En el fondo, es el verdadero problema para la escasez de desarrollos realmente grandes con Lazarus. Un sistema como el nuestro, con docenas de miles de líneas de código, aunque no es imposible, es una locura intentar hacerlo sin un muy buen depurador.

Nuestro enfoque es por ende en dos etapas:

1. Usar Linux como Front-end. Eso, aunque faltaría probar alguito más, y luego dar tiempo de funcionamiento a ver la estabilidad, es algo que creo que ya tenemos bajo control.

2. Poner nuestro servidor en Lazarus/Linux. Aquí estamos avanzando; pero, aún en lo más básico.

Nuestra estrategia es encapsular la funcionalidad de Base de Datos, del Web Module, y alguna que otra complementaria, en nuestra propia capa de abstracción; de tal forma que podamos tener portabilidad Delphi-Lazarus; así mantener ek desarrollo de todo el código propio (bueno, excepto la capa de abstracción), en Delphi, y en Lazarus tan solo hacer alguno que otro ajuste muy mínimo que pudiera ocurrir.

Por cierto, has usado ese depurador con una aplicación de Módulo Apache, o al menos una CGI ?. Es que es ahí donde tenemos nosotros que trabajar y, según leímos, la depuración multihilos anda mal; así que en últimas la alternativa sería depurar el CGI.

Una última pregunta. Yo supongo que el problema de tener un buen depurador integrado se debe haber discutido a fondo en los foros de alto nivel de Lazarus. Y también supongoo que su no implementación se debe a un alto nivel de dificultad. Tienes alguna dirección donde se esté haciendo seguimiento al tema ?. Digo, para estar al tanto de las perpectivas.

No, sólo lo he usado con componentes "normales" y de bases de datos.

Progresamos. Algo funcionó
 

Hola,

Bueno, hoy logramos progresar. Vamos por partes:

1. Tras superar varios problemas, reinstalamos todo y quedamos con la siguiente combinación: Ubuntu 11.04 Naty + Apache 2.2 + Firebird 2.5 + Zeos 7.0.0

2. Un problema fue que en lugar de instalar solo Lazarus, intentamos instalar CodePython; pero, no pudimos. Aunque aparentemente había instalado bien, las cosas no trabajan. Intentamos arreglarlo; pero, como nos hizo perder mucho tiempo optamos por trabajar solo con Lazarus

3. Al repetir la prueba, volvió a fallar. Para ser exactos, el error fué :

Operation is not alloewed in FORWARD ONLY mode

4. Entonces intentamos usando TZQuery en lugar de TZReadOnlyQuery y ahí si funcionó !!

5. La conclusión es la siguiente : TZReadOnlyQuery está optimizado para lo que sería el uso normal de un Query. En esa optimización, debe estar empleando una instrucción que no es soportada en el modo optimizado FORWARD ONLY. Cual instrucción ?. Una busqueda rápida indica que el mensaje es propio de Zeos y està definido en la unidad ZMessages. En Google hay un solo reporte del mismo; pero, bajo otras condiciones. Hoy no nos alcanzó el tiempo; pero, intentaremos ubicarla mañana porque, aunque TZQuery ya nos abre una puerta, en teoría nosotros deberíamos utilizar es TZReadOnlyQuery

6. Aunque es un avance, de todas formas toca probar bastante más. Vamos a ver.

Supongo que ese TZReadOnlyQuery no permite volver hacia atrás en los registros. Normalmente los TDataSet tienen la propiedad "UniDirectional", para indicar si sólo avanza hacia adelante o si guarda información para poder volver hacia atras.
Por lo visto ese tzreadonlyquery es como un TIBQuery o un TFIBquery, que tienen siempre el UniDirectional a False, para ocupar menos memoria y ser más rápido, es perfecto para consultas, informes, etc. Pero si si quiere hacer un mantenimiento presentando datos y que el usuario los recorra a su gusto... entonces no valen, hay que usar el TIBdataset o el TFIBdataset, estos son de IBX y FIbplus, respectivamente.
O sea, el "fallo" que te aparece no es un fallo, es una característica de ese componente que lo estábais usando indebidamente.

Debe ser unidireccional
 

Hola,

Nosotros estamos trabajando es en un servidor. El componente no existe en el lado cliente; nuestro esquema correcto es avanzar solo hacia adelante (FORWARD ONLY) y el mensaje de error confirma que efectivamente el componente se está comportando bien.

En ese sentido, tal componente no debería ni siquiera tener esa propiedad, ya que se supone que es su comportamiento natural. De todas formas, tú idea puede estar en la dirección correcta, al suponer un mal uso de una propiedad, por lo siguiente:

Nosotros solo cambiamos, Name, Database y SQL; pero, nuestro sistema de prueba está lento porque usamos es máquina virtual en un equipo con poca memoria; así que yo ayer estaba pensando que quizás al ajustar las propiedades del componente accidentalmente modificamos alguna. No hay que descartarlo. Hoy revisaremos.

Bueno, no sé si será eso o no, era sólo una idea para que puedieras verificarlo.

Si usas una máquina virtual entonces asegúrate de tener suficiente memoria RAM para el servidor y para el "servido" :)
Si tienes más de una cpu (física o virtual) también ponlo en la configuración, notarás la diferencia de la MV.

Era un problema de Zeos
 

Hola,

Ya verificamos y efectivamente se trata de un problema de Zeos. Nosotros hicimos una corrección al código fuente de Zeos, lo reconstruímos y ya trabajó bien.

Más tarde les daré una explicación detallada porque el arreglo fué de emergencia; quiero estudiar más a fondo el código Zeos para determinar con mayor exactitud la causa e implicaciones tanto del problema como de la solución que aplicamos.

Les adelanto que al avanzar en las pruebas encontramos otros dos problemas que potencialmente son de mucha importancia. Uno es quizás una limitante de Zeos y el otro un problema de diseño del Web Module. Vamos también a analizarlos en detalle antes de reportarlos aquí

Saludos

Aunque ZEOS ha sido un buen proyecto, pienso que no sería recomendable usarlo en futuros desarrollos. Basta fijarse en su portal para darse cuenta de que no ha habido cambios ¡en casi dos años!

Además, la versión 7 se quedó en alpha, o sea, nada recomendable para producción :(

// Saludos

En principio el argumento es válido; pero ...
 

Hola Roman,

Gracias por aportar.

En principio, el argumento es válido; pero, consideremos lo siguiente:

1. Si no es Zeos, quién ?. Nadie nos ha sugerido ninguna otra opción que satisfaga nuestras condiciones. Han planteado opciones amarradas a un solo motor de Base de Datos, y eso es inaceptable.

2. En realidad si hay un trabajo más nuevo. La versión 7.0.1. En esta página puedes encontrarla :

http://zeosdownloads.firmos.at/downloads/snapshots/

3. Todos nos dicen que Zeos es muy bueno. Una vez estabilizado, como tenemos los fuentes, en el peor de los casos nosotros mismos podríamos corregir errores y agregar características. Lo primero ya nos tocó hacerlo y lo segundo parece que también porque hasta donde hemos mirado no está soportando parámetros BCD. Bueno, eso es una adelanto de los otros problemas que les dije que revisaremos mañana

Je, je. Tienes razón en lo que acotas. Pero dime, ¿estás seguro de querer lanzar tu programa con una versión alpha? Es cierto, como dices, que al disponer del código fuente puedes tú mismo modificarlo, corregir errores; pero, los errores que has detectado, ¿serán todos? ¿No habrá por ahí una liebre que te salte en el momento menos esperado?

Quizá lo que habría que plantearse es el el uso de Lázarus como herramienta de desarrollo. Pero mejor no lo digo porque me vas a preguntar por alternativas :p

// Saludos

Ese es el punto más delicado
 

Hola Roman,

Ese es el punto delicado. Ciertamente, puede haber más errores, o limitaciones, y, honestamente, por lo que hemos visto hasta ahora, estamos esperando que haya varios más de importancia.

La ventaja que tenemos es que, por nuestra metodología, el uso de características no solo de Zeos, sino del propio Lazarus, es reducido.

Entre otras cosas, por lo mismo que anotas, es que no hemos considerado la posibilidad de usar Lazarus en el lado del cliente. En el lado del servidor, recuerda que nuestro desarrollo está es en Windows con Delphi. La idea de tenerlo en Linux es disponer de una alternativa atractiva a ciertos clientes. Esto de ahora es un trabajo exploratorio para nuestras opciones de largo plazo, no planeamos hacer la migración en este momento.

Por otro lado, estás planteando que Lazarus no es una herramienta confiable para desarrollos realmente serios de programación, y esa es una posición dura. Me gustaría si alguién pudiera orientarnos con algún enlace a donde se discuta el tema a fondo con gente que haya desarrollado algo realmente grande.

Nuestra opinión es cercana a la tuya en el sentido de que no es una herramienta suficientemente madura para un desarrollo serio por si misma. La falta de un muy buen depurador, y otras características que hemos visto, así nos lo hacen pensar.

Sin embargo, como la lógica la estamos desarrollando en Delphi, creemos viable pasarlo a Linux, sobre la Base de tener una capa de abstracción propia, de forma que el código nuestro tanto en Delphi como en Linux, excepto en ciertos casos especiales, sería siempre el mismo.

Ahora, tienes razón en que te voy a preguntar por alternativas. Tienes alguna viable ?. Ten en cuenta que pasar a otro lenguaje que no siga una sintaxis muy similar a Delphi sería muchísimo peor en términos de tiempo de desarrollo, ya que nosotros contamos con docenas de miles de líneas de código

Pues aplicaciones hechas con lazarus que conozca, estas:
http://www.peazip.org/index.html
http://code.google.com/p/transmisson-remote-gui/
http://forge.lazarusforum.de/projects/lazupdater/
seguro que hay muchos mas, pero estos son los que se me vienen a la mente xD

PD. se me olvidó esta galería http://wiki.lazarus.freepascal.org/L...cation_Gallery

Buen punto de referencia; pero ...
 

Hola,

Muchísimas gracias por la información. Es un buen punto de referencia; pero, creo necesario anotar lo siguiente:

Por supuesto que hay programas hecho en Lazarus, y bastantes más que los mencionados; pero, yo me refería a sistemas realmente grandes, no a programas especializados. Me centro en grandes porque en un programa especializado hay mucho más margen para atender los inconvenientes.

Para ser claro, en nuestro caso, cuando hablo de un sistema grande me refiero a uno que integre simultaneamente muchas tecnologías y / o maneje grandes volumenes de datos, requiriendo multiples procesamientos de los mismos.

Nosotros manejamos mucho http, tanto en cliente como en el Web Server, correo electrónico, encriptación, compresión de datos, edición de documentos sgeuros con RTF, gráficas dinámicas (con TeeChar), muchísmo de Base de datos (ya nos acercamos a 500 tablas). estructuras de árbol, administración documental, algunos centenares de reportes impresos, incluyendo trabajar con formas preimpresa, etc.

Este tipo de desarrollo requiere una herramienta que permita depurar facilmente y que no haga perder tiempo obligando a cada rato a analizar código de terceros para corregir inconvenientes.

De las aplicaciones que listas, solo un par parecen acercarse algo a alguno de nuestros módulos; el resto son manejos muy especializados, que incluso, en su mayoría no usan Bases de Datos, o hacen un uso mínimo.

La pregunta importante es : alguién de este foro tiene experiencia programando este tipo de sistemas con lazarus ?.

Es que una cosa es la teoría y otra es la práctica; por eso quiero insistir en esta pregunta, y aclaro, no es con ánimo de molestar a nadie sino para valorar mejor la realidad del uso de Lazarus, para los propósitos mencionados, entre nuestra comunidad.

Para ello tienes que ir a brazil, hay muchos sistemas grandes que hacen lo que planteas, pero no son abiertos, lo del depurador es mentira, ya me cansé de que digan que es muy malo y demás, es un buen depurador y hace lo que se requiere, yo personalmente me he sentado a depurar, al inicio no encontraba nada, pero para encontrar hay que buscar, en el menú ver, ventanas de depuración, tienes lo básico para depurar bien, hilo que depuras, variables, histórico, ensamblador, puntos de interrupción y de observación, obviamente, no es comparable con el depurador que trae el VS2010 que me parece fabuloso, pero no la basura que suelen decir que es, synapse hasta donde sé es el mejor paquete de clases para manejo de http, ftp, https y demás protocolos, la encriptación con componentes DCrypt o por SHA1.pas que trae por defecto la LCL, el TChart está bastante completo y si es necesario presentar gráficas mas bonitas para eso dispones de AGG.Pas, el acceso a base de datos no hay nada como DBExpress excepto por Zeos, sin embargo todos los controles estandar de SQLDB pueden interactuar con cualquier componente de conexión de la misma paleta, así que esa implementación sería simple, por el lado de reportes no puedo decir nada, ya que no poseo experiencia con LazReport ni con FortressReport, Finalmente, como decimos por acá, "el mal trabajador siempre le hecha la culpa a la herramienta", un ejemplo de que lazarus sirve para mucho es FactuLinex, aunque las personas que se han encargado de portarlo de kilyx a lazarus tienen problemas de código spaggeti, FactuLinex funciona muy bien.

Bien. Comentarios
 

Hola,

Gracias por las anotaciones.

Si entiendo bien, implícitamente estás diciendo que posees experiencia con todo lo mencionado excepto con reportes. Eso es correcto ?

Ahora, también implícitamente, estás confirmando que no se tiene una solución del más alto nivel en el tema de acceso a Base de Datos.

Al respecto, y hasta donde hemos visto, un punto central es que el cubrimiento de múltiples motores de base de datos no es lo amplio que teníamos en el BDE o con dbExpress.

Y también en relación a eso, adelanto que uno de los dos problemas fuertes que mencioné antes y que quiero tratar en hilo aparte es precisamente otra característica que aparentemente no está implementada en Zeos y que es vital para nuestro manejo. Falta verificar si se trabajó en la última versión de Zeos. Creo que hoy pongo el hilo

Sobre el depurador integrado, nosotros no lo hemos probado porque cuando intentamos usarlo nos cierra Ubuntu en la máquina virtual. La causa ?, Según el log de errores es falta de memoria; un problema adminstrativo que estamos en espera de que se resuelva.

Sin embargo, como bien dices, lo que hemos leído no son buenos comentarios, ya que sugieren que se use un depurador externo. Aparte de eso, la revisión que hemos hecho del código fuente de CGI indica que aparentemente para depurar aplicativos Web hay que estar colocando a cada paso del código inserciones condicionales de código específico de depuración (Condicionales CGIdebug), lo cual nos hace pensar que no es nada facil depurar el servidor. Puedes confirmar eso ?. Has depurado aplicativos Web usando el depurador integrado ?. Que diferencia tiene con el disponible bajo Delphi ?

Hola, como bien dices, para Lazarus no hay un dbExpress o BDE, lo mas parecido es Zeos, que como bien dice Roman, el avance es casi nulo, pero una forma facíl de implementar esto (definiendo si basta con las conexiones de la pestaña SQLDB) es remplazar el TSQLConection por la necesitada, no es muy complicado de implementar por código, yo lo he hecho para MSSQL y Firebird, que son las que he necesitado, hasta el momento, ahora y lo mas complicado, lo que quieres es hacer un modulo CGI para Apache Lazarus no lo puede Depurar como lo hace Delphi o VS, el por que es simple, para Delphi y VS en tiempo de ejecución se genera un servidor en memoria por ellos mismos para atrapar todas las llamadas, pero en Lazarus esto nunca sucede, solo se genera el ejecutable y se pone en el servidor, una forma de detectar esos errores es esta http://wiki.lazarus.freepascal.org/A...L-Android_Appl, personalmente no me gusta y acá te dejo una pregunta, que necesidad hay específicamente para que sea un CGI? dependiendo de esto podríamos tener una alternativa a la necesidad.
Se me olvidaba el Debug Server, pero igual sigue sin gustarme.

Voy a "Meter la cuchara":

Me da la sensación de que quieren sacarle provecho inmediato tanto a Lazarus como a Linux, intentando hacer las cosas de la misma manera en que se hacían en Windows (y el Delphi), y eso es un grave error porque son diferentes.

Tienes toda la razón compañero rretamar, por eso mismo creo que hay que mirar la necesidad, exactamente como necesidad, no como hasta ahora que es "hacer la misma implementación hecha en Delphi" sino mas bien algo como, es necesario que una aplicación cliente se comunique con una aplicación servidor por X protocolo y que devuelva X resultado, para lo último, yo sugiero un Servicio o Daemon, que use protocolos comoHttp, TCP o UPD, pero algo exactamente igual a lo hecho en Delphi muy dificilmente puede ser implementado en Lazarus.

Pues yo no veo que este sea el caso. El compañero rolandoj ha dicho, por ejemplo:

es decir, está hablando de necesidades generales. ¿En dónde se vislumbra que quiera resolver todo de la misma manera que en Windows?

// Saludos

En necesitar hacerlo en CGI, solo por eso lo digo, en si a lo que me refiero es replantear el usar CGI por alguna otra alternativa..

Aclaración
 

Hola,

Gracias a todos por participar.

Aclaro la situación:

1. No hemos pensado desarrollar con CGI sino con módulos Apache. Empezamos las pruebas por CGI porque se suponía que era el modelo más sencillo de manejar. Nosotros en Windows usamos es ISAPI. Hasta donde tenemos conocimiento, para producción, el equivalente en Linux son los módulos Apache; y para allá es en últimas a donde vamos

2. La idea si es hacer las cosas lo más parecidas a Delphi posibles, por una razón muy sencilla: Nos es inviable, en términos de costos, tiempos y logística, pretender armar algo independiente.

3. Lo que queremos es montar una capa de abstracción que brinde servicios básicos, de tal forma que sea la única diferente entre ambas plataformas (con alguna que otra excepción, porque ya vimos que no podríamos hacerlo al 100%). Esa capa la tenemos montada en Windows porque nos preparamos desde un principio para soportar más de una plataforma. La idea es migrarla a Lazarus - Linux; de esa forma, una vez estabilizada, salvo casos excepcionales, podríamos mantenernos desarrollando un solo código para ambas plataformas.

Hola Rolando,

En cuanto a Zeos creo que las últimas versiones de trabajo ahora se encuentran aquí:http://zeoslib.svn.sourceforge.net/ -- cambiaron la ubicación, y parece que están por la revisión 932.

Por lo que he visto, creo que solo hay un desarrollador verdaderamente activo llamado markdaems que va manteniendo el código, pero ya ha comentado en alguna ocasión, que dada la tarea y recayendo en unas solas espaldas la cosa va lenta. Ellos están esperan como lluvia del cielo colaboradores para el proyecto, creo que si tenéis aportaciones al código lo mejor será contactar con ellos para ver si se pueden incorporar. Desde luego Zeos es un proyecto importante para Delphi y Lazarus.

Saludos!

Geolife



--------------

Vaya, entonces ese es el problema, que el pobre está solo, sin ayuda. Resulta extraño dado la gran difusión que tienen esos componentes. Supongo que debería poner un un mensaje de aviso para encontrar personas que ayuden, porque en cualquier momento se cansa o se aburre y se acaba el proyecto.

Hola Casimiro!

Llevas toda la razón del mundo!

En algún mensaje de los foros a veces se le ha visto asediado y pidiendo amablemente cualquier colaboración. La verdad es que uno solo, puede quemarse fácilmente con un proyecto de esa envergadura. Y como tu dices, es extraño y una pena al mismo tiempo que con lo conocidos y utilizados que son estos componentes, no haya más mentes que le dediquen un poco de atención.

Hace no mucho, ha trasladado el desarrollo a SourceForge, aquí se puede ver los cambios que van realizando al código fuente y las aportaciones:
http://sourceforge.net/projects/zeoslib/develop