Xailer & OZ Software

El nuevo RDD de xHarbour para SQL sera compatible con Xailer?

Actualmente no somos compatibles con el compilador de xHarbour.com,
esperamos serlo en un corto plazo, y hasta que no seamos compatibles con
ellos no podrá utilizar dicho RDD ya que sólo se encuentra en dicha versión
de xHarbour comercial.
Por otra parte, Xailer propone, incluso para DBFs, la no utilización del
enfoque RDD y prefiere un enfoque completamente OOP, y para ello utiliza su
tecnología de Datacontrols, la cual permite acceder a motores SQL YA y de
una forma muy superior a cualquier RDD. En mi opinión el sistema RDD es
arcaico y sólo valido para DBFs. Es un completo error intentar acceder a un
motor SQL a través de RDD.
No obstante si no utilizase DataControls, el día que fuesemos compatibles
con xHarbour.com podrá utilizar dicho RDD sin problemas.
Espero que otros usuarios del foro le puedan comentar las ventajas de los
Datacontrols respecto al RDD.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Foro xailer" <borischesini@masterisi.com.ar> escribió en el mensaje
news:[email=46a75467@ozsrv2.ozlan.local...]46a75467@ozsrv2.ozlan.local...[/email]
> El nuevo RDD de xHarbour para SQL sera compatible con Xailer?
>

Con respecto a este tema... a mi me parece una buena idea.
En mi caso particular, vengo migrando mi aplicación, que es única y la tengo
instalada en mas de 100 usuarios, desde su versión original en Clipper, y
todo mi trabajo en Xailer ha sido pensado de manera de tratar de modificar
lo menos posible el código original. Con esto he ganado velocidad a la hora
de la migración.
Hoy tengo toda mi aplicación, que es un sistema de gestión completo, que va
desde facturación hasta el balance general final (explico esto para que
tengan una noción del tamaño de la misma) en Xailer, con entorno visual (de
hecho estoy mas que satisfecho con Xailer y sus prestaciones).
Dado que el 99 % de la aplicación está codificada (en tiempo de diseño, SOLO
tengo el formulario inicial, despúes todo se crea en tiempo de ejecución)
esta idea del RDD para SQl, si bien entiendo no debe ser lo mejor y lo mas
óptimo, me daría la posibilidad de migrar de manera mas rápida mi aplicacion
(que todavía está en DBFs, es una aplicación que lleva 10 años en el mercado
y no es tan fácil migrarla y a su vez no desatender a los clientes) a SQL.
Mi objetivo próximo inmediato, es comenzar a migrarla a SQL, así que me
gustaría me tengan al tanto con el RDDSQL.
Saludos

Sigo pensando que un RDD para SQL para trabajar con las tablas "a la DBF" es
lo más parecido a un atraso que a un avance. El RDD trabajará con tablas
unicas o con consultas, pero jamás permitirá la flexibilidad de SQL y OOP.
Tenemos que pensar, de una vez por todas, en dejar de usar los comandos
xBase para el uso de ficheros, incluso para los DBF: restan potencia al
acceso de datos por muy cómodos que sean.
Un saludo
Jose A. Suarez
"Mariano Filippi" <marianofilippi@masterisi.com.ar> escribió en el mensaje
news:[email=46a7c41a@ozsrv2.ozlan.local...]46a7c41a@ozsrv2.ozlan.local...[/email]
> Con respecto a este tema... a mi me parece una buena idea.
> En mi caso particular, vengo migrando mi aplicación, que es única y la
> tengo instalada en mas de 100 usuarios, desde su versión original en
> Clipper, y todo mi trabajo en Xailer ha sido pensado de manera de tratar
> de modificar lo menos posible el código original. Con esto he ganado
> velocidad a la hora de la migración.
> Hoy tengo toda mi aplicación, que es un sistema de gestión completo, que
> va desde facturación hasta el balance general final (explico esto para que
> tengan una noción del tamaño de la misma) en Xailer, con entorno visual
> (de hecho estoy mas que satisfecho con Xailer y sus prestaciones).
>
> Dado que el 99 % de la aplicación está codificada (en tiempo de diseño,
> SOLO tengo el formulario inicial, despúes todo se crea en tiempo de
> ejecución) esta idea del RDD para SQl, si bien entiendo no debe ser lo
> mejor y lo mas óptimo, me daría la posibilidad de migrar de manera mas
> rápida mi aplicacion (que todavía está en DBFs, es una aplicación que
> lleva 10 años en el mercado y no es tan fácil migrarla y a su vez no
> desatender a los clientes) a SQL.
>
> Mi objetivo próximo inmediato, es comenzar a migrarla a SQL, así que me
> gustaría me tengan al tanto con el RDDSQL.
>
> Saludos
>

Insisto...
No se trata de que sea mejor o peor (en mi caso... a lo mejor no se entendió
lo que expuse...)...
Es una cuestión de tiempos...
Cuando hay tiempo, ni hablar que se busca lo mejor...

Hola Mariano,
> Dado que el 99 % de la aplicación está codificada (en tiempo de diseño,
> SOLO tengo el formulario inicial, despúes todo se crea en tiempo de
> ejecución) esta idea del RDD para SQl, si bien entiendo no debe ser lo
> mejor y lo mas óptimo, me darí­a la posibilidad de migrar de manera mas
> rápida mi aplicacion (que todaví­a está en DBFs, es una aplicación que
> lleva 10 años en el mercado y no es tan fácil migrarla y a su vez no
> desatender a los clientes) a SQL.
>
> Mi objetivo próximo inmediato, es comenzar a migrarla a SQL, así­ que me
> gustarí­a me tengan al tanto con el RDDSQL.
Si me permites mi opinión... Creo que el planteamiento de ir migrando una
aplicación 'a lo dbf' de forma rápida a un entorno cliente/servidor de bases
de datos usando SQL como lenguaje de acceso a datos va a hacer que trabajes
dos veces. Una para hacer la aplicación y la otra para rehacerla otra vez,
pero 'a lo SQL'.
La programación diseñada para trabajar con tablas dbf es conceptualmente
distinta a la programación orientada a un modelo de datos cliente/servidor
donde el programador 'no es el propietario de los datos'. Si comenzamos una
nueva aplicación traspasando las tablas dbf a un SQL Server (por poner un
ejemplo) tal cual, y abordamos la programación con la misma lógica vamos a
hacer que nuestra aplicación sea altamente ineficiente. Y me repito:
altamente ineficiente.
Saludos,
José Luis Capel

La cuestión "de tiempo" es trabajar una sola vez y hacerlo bien.
Cuando nos planteamos la migración a SQL también debemos plantearnos
rehacer la aplicación y, de camino, pulir el código de esas funciones
multiuso que tenemos y reorganizarlas.
Lo otro es aplicar parche sobre parche para salir del paso haciendo
chapuzas cada vez más difí­ciles de mantener. Y se lo que me digo, que ya
he pasado tres o cuatro veces por esto.
Que yo sepa, casi todos los que estamos aquí­ hemos soñado con reutilizar
el máximo código posible de nuestra aplicación pensando en ahorrar
tiempo, y al final lo que hemos hecho ha sido perder un tiempo precioso
durante el que se podí­a haber avanzado rápidamente con un nuevo
desarrollo que, de paso, además de contemplar las funcionalidades
actuales de la aplicación, añada algunas novedades que hagan la nueva
versión atractiva al usuario.
En fin, todo esto para seguir diciendo que un RDD para SQL es una
obsesión y un atraso que hace perder potencia al SQL.
Saludos
Jose A. Suarez