De Win-Delphi-MSSQL a Linux-Delphi-Oracle

[Trevian]

Hola

Tengo un sistema ERP ya bastante grande, mas de 5 años de trabajo funcionando correctamente, en Win + Delphi 7 + MS Sql Server 2000 (ahora 2005)

Tengo un posible cliente que lo quiere en Oracle, pues el ya tiene el Oracle (realmente no le pregunte que versión de Oracle tiene) es decir seria Delphi - Oracle

También prefiere que sea en Linux

Bueno por pasos:
1ro - El caso o de la BD (SQL-Oracle)
Quisiera saber si es conveniente el traspaso, uso ADO como conexión, seria tan complejo el traspaso, tendría que convertir la BD a Oracle, los Stores me imagino que algo debe fallar, las conexiones es otro caso, abra que volverlas a rehacer, etc...
o con que argumentos podría convencerlo para que no lo haga

2do Win a Linux
Me imagino que si en el servidor tiene Linux con su Oracle, los puestos de trabajo podrían seguir en Win con Delphi

Saludos

Trevian

[[AzidRain]]

Si el cliente te va a pagar los costos de hacer tanta migracion ( lo dudo) pues adelante, en el caso de productos ya desarrollados al cliente no se le debe dar opción salvo que desee pagar los costes, lo cual es muy raro. Se le presenta el producto tal cual con sus costos, si desea otra cosa pues bueno, entramos al terreno de la negociación. Y como mencionas parece que tienes un producto ya muy maduro como para andarle haciendo cambios solo por un cliente. Insisto, si ese cliente entiende que hacer eso le va a costar quizá mas caro que el producto en sí ,adelante, de lo contrario no pierdas tu tiempo. No malbarates tu trabajo en aras de lograr un nuevo cliente.

[Neftali [Germán.Estévez]]

La clave está en tu aplicación (dónde la vas a ejecutar). Si los puestos cliente son Windows, te sirve la misma aplicación, si los puestos no son Windows, ¡estás jodido! (NOTA1)

Parece que estás usando ADO para acceder a SQLServer. Cambiar para acceder a Oracle no es difícil, ya que puedes mantaner la conexión ADO. En ese punto se presentan los problemas:

(1) Las SQL de Oracle, no son precísamente las más estandard. Dependerá de cuantas tengas y la complejidad de estas que te dará más problemas o menos.

(2) Como ya te he dicho se puede acceder a Oracle vía ADO. No funciona mal del todo, aunque hay otros compoentes mejores (por lo que he leído). Si el rendimiento te obliga a cambiar los componentes de conexión es un trabajo añadido.

(3) El tema de la programación en Base de datos ya es otro cantar. No comentas cuanta programación tienes en la Base de Datos. No es lo mismo reescribir 10 Stored procedures y unos cuantos triggers, que si tienes 120 de ellos.

En general creo que das pocos datos para una cuestión tan compleja. Esto que estás proponiendo no es un trabajo de 15 días. Y además hay que plantearse que depende que cómo lo hagas, puedes llegar a funcionar, pero si esl rendimiento no es bueno, no sirve de nada...


(NOTA1) En ese supuesto quedaría una configuración posible, que sería la de montar un servidor de aplicaciones con Terminal Server y conectar los clientes Linux a ese TS. Pero lo mismo de antes. Esta configuración tiene muchas connotaciones y hay que decidir sies posible en cada caso concreto.

[Trevian]

Hola amigos

Pues son muchos Store Procedure unos 600 todo el sistema y un Modulo de Administracion totalmente hecho en SQL Server.

Creo que todo esta en el precio que este decidido a pagar y para cuando lo quiere, pues se puede hacer calmadamente modulo a modulo, solo despues que analice algunas cosas mas.

Tambien es importante eliminar linux al menos de esta primera variante y que solo sea en el servidor en una segunda fase.

Voy a seguir viendo el asunto con el cliente pues aun no se que Oracle tiene y ver bien la compatibilidad de ese SQL con el T-SQL.

Tambien checar bien lo de las conexiones y si el ADO seria eficiente, creo que lo correcto seria usar el dbExpress?.

Mas las sorpresas que pudierana aparecer en el cambio.

Saludos, muchisimas gracias

[Neftali [Germán.Estévez]]

Empezado por Trevian

Pues son muchos Store Procedure unos 600 todo el sistema y un Modulo de Administracion totalmente hecho en SQL Server.
...
Voy a seguir viendo el asunto con el cliente pues aun no se que Oracle tiene y ver bien la compatibilidad de ese SQL con el T-SQL.

¿Una pregunta?
Dado ese volumen y el precio/tiempo que va a costar adaptarlo, sin contrar los errores que van a aparecer en el cambio y los posteriores problemas que vas a tener si haces modificaciones o corriges errores (ya que tendrás que mantener dos sistemas en paralelo).

¿No habría la posibilidad de que el cliente instalara un SQL Server?
A día de hoy un SQl Server en una buena máquina puede tirar de cientos de usuarios. ¿Realmente es necesario el cambio?
Lo comento sólo para que te lo plantees y tal vez se lo plantees al cliente.

[sinalocarlos]

Pues metiendo las narices en el asunto, si el costo del desarrollo va incluido en precio y el cliente se anima, es buena oportunidad para dar el paso.

Como consejo, y no es comercial, dale un vistazo a Remobjects con Dataabstract, si ya vas a hacer todo el cambio valdría la pena dejar la aplicación ya en tres capas con soporte a múltiples bases de datos y no solo MSSQL/Oracle.

esta plataforma esta bastante robusta y ademas te permite adaptar diferentes motores de bases de datos de forma relativamente simple http://www.remobjects.com/

Saludos

[[AzidRain]]

Estoy de acuerdo con Neftali, hoy en dia muchos clientes se empeñan en mantener lo que ya tienen solo por no gastar 2 o 3 pesos mas. A veces ni siquiera saben de que estan hablando pues estan asesorados por sus "gurúes" de programación. Muchas veces pasa que como el "gurú" solo sabe usar una u otra herramienta quiere que todo lo que la empresa compre sea de acuerdo a lo que él pide. Es algo así como si tuvieras tu ERp perfectamente funcionando y solucionando problemas en Win y te pidieran que lo pasaras a Linux porque el "jefe" de sistemas lo sugiere (pq no le gusta win o bien ya tiene todo en linux). En este negocio de las aplicaciones verticales (las que ya estan pre-diseñadas) no podemos darnos el lujo de andar cumpliendo deseos, pues nuestra visión desde el inicio es una tratando de que le sirva a la mayor cantidad posible de clientes. Y a veo a alguien pidiendo que le hagan una version de "Final Cut" para windows porque no tiene Macs o bien a alguien que pida un "AutoCAD" para Mac (hubo intentos por cierto). Si tu solución vale la pena y sobre todo insisto, le resolverá sus problemas y mejorará su productividad (de tu cliente) lo de menos es sobre que corra. Hay miles de empresas aun corriendo AS/400, UNIX y hasta MSDOS que no han cambiado simplemente porque la solución que tienen les satisface, entonces, no veo pq cambiar años de desarrollo solo pq un cliente lo quiere de otra forma.