claro que fué sin saberlo y por eso precisamente lo dije de la siguiente manera:

Aclaré que no lo sabia y que de no soportarlo sería algo por agregar a la larga lista de "cosas" que no soporta.

Jamás me mostré como un experto en firebird sin saber del tema. :) No conozco firebird tan a profundidad como para poder declarar que no soporta algo.

O sea, ¿es curioso sólo cuando la idea es buena? :p

¿O te refieres a sí, la idea es buena, es curioso...? :D

// Saludos

Me comí la coma :p

Ya, y también puede ser algo a agregar a interbase, mongodb, informix, netezza, ingress, sqlite, dbase, foxpro... :confused:

pues si.. solo que en este hilo se delimitó desde el inicio claramente a Firebird... o me equivoco?

En eso te doy la razón.

Exacto¡¡¡¡¡¡¡¡... precisamente la técnica solo es útil para cuando debes hacer múltiples consultas a la base de datos para traterte varios recordsets.


caray Román, pues ahí si que puedo decirte, siempre he creido que esa parte está ligada al conocimiento que tenga el diseñador de la administración de bases de datos, del diseño de la base de datos y de la puesta a punto del motor.

Yo tengo un sistema con php y mysql con tablas de más de dos millones de registros y tamaños del órden de gigas de información. y me responde extremadamente rápido con procedimientos almaceandos con una carga de más de 50 usuarios simultáneos escribiendo y consultando.

Tendría que revisarlos. Porque ciertamente no soy ducho en eso. Se trataba de uns procedimientos que se limitaban a hacer sencillas operaciones de stringsy numéricas para, por ejemplo, calcular el dígito verificador de la homoclave de un RFC. Y era muy lento. Es decir, no había realmente consultas a la base, de manera que pienso que no entraban en juego cuestiones de diseño.

// Saludos

Y con DBExpress?
 

Bueno al margen de lo demás.

Si utilizamos DBExpress + DataSnap estas soluciones de traer conjuntos de datos con sus "hijos", y los hijos de sus hijos, y los hijos de los hijos de sus hijos, etc. se pueden implementar muy facil. Lo mejor es que no importa si el motor lo soporta o no.

Mas o menos ventajas? no se.

Saludos.

Personalmente uso más ADO que DbExpress así que si te animas a compartir como se hace con esos componentes sería muy interesante y útil para la biblioteca de técnicas. Saludox

Con DBExpress pero sin DataSnap
 

Así de rapidito hice un pequeñito ejemplo con DBExpress pero sin dataSnap para ilustrar lo que me pasó por la mente cuando vi el tema.

Para los que quieran profundizar en el tema pueden ver:

La cara oculta de delphi 6: Paginas 705-707 para empezar.

Si esto no pega con el tema de conversación, ehhh. Bueno, a alguien le servirá.

Saludos.

Osorio amigo mio mucahs gracias¡¡¡¡¡¡¡¡... si me lo permites lo revisaré y lo trataré como una entrada en mi blog...

Un saludo

Hagale, con tal que le sirva a la comunidad.


Saludos.

Hola a todos, he leído el hilo, aunque me ha parecido poco interesante y nada constructivo. No entiendo cosas que se han dicho y entiendo que cosas que se han dicho tendrían mejor aceptación si se hubiesen dicho de otra forma.

Aunque no es el tema de este hilo, me gustaría dar mi opinión sobre algo que se ha comentado. Me ha parecido entender que las cosas son buenas por ser gratis o quizá las cosas gratis son buenas...

Yo utilizo firebird y estoy muy contentó con el en muchos aspectos. Puede que tenga carencias, pero por ahora no he necesitado las cosas de las que carece, o las he cubierto fuera del motor, o quizá sí tuviese más funcionalidades las utilizaría. Firebird, desee mi punto de vista,no es un producto gratuito, aunque lo puedes descargar y utilizar sin coste alguno. En el hay un equipo de personas que trabajan y viven de el y es un proyecto que seguirá vivo, mientras haya gente que lo apoye, principalmente económicamente. No creo que existan cosas "gratis". Creo que firebird tendría muchas más funcionalidades si la comunidad de usuarios le devolviera algo de lo que firebird ha dado a la comunidad. Eso permitiría que se evolucionase y que cada vez nos proporcionase más servicios y características.

Si firebird no ha evolucionado en mayor medida es porque no ha tenido el apoyo económico que puede haber tenido mysql o postgresql y al final todo depende de dinero, aunque sea "gratuito". ¿Vosotros trabajaríais gratuitamente con el único aliciente que en los foros digan que vuestro trabajo es bueno por qué a gente que se aprovecha de él diga que le ha salido gratis? ¿Cuanto tiempo soportaría vuestra empresa trabajando gratuitamente?.

Firebird, como muchos otros proyectos te permiten empezar algo sin coste en licencias, pero su objetivo final es que si tienes éxito, devuelvas algo de lo que firebird te ha dado. Es algo de lo que deberíamos ser conscientes. Si preocupa el futuro de firebird, deberíamos empezar a plantearnos como apoyar lo económicamente. La ventaja de este tipo de proyectos es que no requiere un coste fijo y cada uno lo puede apoyar en mayor o menor medida, pero al final ese apoyo permitirá que siga vivo y en continúa evolución.

Por otro lado, el tema del hilo quizá se podría solucionar con GTT. Un procedimiento almacenado puede almacenar registros en tablas temporales y dichos registros pueden ser visibles a nivel de conexión o transacción, por lo que una vez rellenados los registros desde el procedimiento almacenado, se podrían recuperar mediante DML desde la aplicación. De esta forma, tendrías como resultado tantos recorsets como desees.

Totalmente de acuerdo... y es una lástima que precisamente Open source signifique para muchos "gratis" y lo peor es que cobren por ello y jamás devuelvan a la comunidad parte de las ganancias....

Indudablemente, yo se de algunas casos; que pudiendo por lo menos dar unas palabras de aliento, ya no digamos apoyo económico que pareciera mucho pedir, y no lo hacen. Es triste pues, pero que le vamos a hacer.....

"Es difícil hacer que un saco vacío se pare derecho"
-Benjamín Franklin

Si amigo... y lo peor es que muchos de ellos, son precisamente los que defienden a capa y espada la "gratuidad"....

En fin, remarco tu cita


"Es difícil hacer que un saco vacío se pare derecho"
-Benjamín Franklin

Y, ¿por qué no habrían de hacerlo?

Cito aquí textual del sitio de firebird:

Es decir, en el caso de Firebird, significa exactamente eso, gratis.

Cierto que los siguientes dos párrafos dicen:

Pero eso ya queda a la conciencia de cada quien. Pero de que es gratuito como en free beer, me parece que es bastante claro.

// Saludos

Si y no, es decir, si es gratuito, pero si queremos que siga así, hay que apoyar de forma económica por pequeña que sea, ya que las personas que desarrollan Firebird, y otras muchos mas RDBMS libres, necesitan comer, y si el proyecto no les da de comer se van a una empresa a trabajar por el pan de cada día.

Saludos.

Muy cierto.. al final ellos que desarrollan hacen una inversión en Luz, alimentos, tiempo.. me parece terrible escudarse en una licencia para no devolverles parte de lo invertido....