Hola Alejandro, no tendrá algun error el nombre del Site www.postrgres.org.ar ? no consigo entrar, además serias tan amable de darme el nombre de algún foro de postgreSQL. En español preferentemente. Quisiera explorar ese mundo. Alfonso
----- Mensaje original ---- De: Alejandro mbs <[EMAIL PROTECTED]> Para: GUFA List Member <[email protected]> Enviado: viernes, 25 de abril, 2008 2:17:36 Asunto: [GUFA] RE: SQL o qué? Estaban Te voy a contar mi caso, es muy parecido al tuyo, primero mis aplicaciones ( un ERP para empresas de salud ), estaba desarrollada en vfp 9 con dbfs, y no todavia no estabamos conectados en linea, y desarrollamos una aplicacion para sincronizar bases dbfs entre varios puntos, utilizando FTP, esta estaba muy piola porque teniamos servidores en todos los puntos y corria muy bien, ya que todo era local. Luego instalamos VPN, y como teniamos desarrollado todo en 3 capas, las consultas se ejecutaban en los componentes en el servidor central, y los datos viajaban a las terminales en XLM, cuando esto funciona muy bien cuando el volumen de informacion es poco, cuando empezamos a pasar bases importantes en volumen empezamos a ver que tardaba mucho en responder y claro no nos olvidemos que hay un pazo de conversion de dbf a XLM que demora cuando la informacion es mucha. Entonces dijimos es hora de migrar a una base de datos y elijimos POSTGRES, ya que hay mucha informacion en internet, muchos foros, y se habla muy bien de el, y es libre, no pagas, nada, casi te lo comparan con oracle, y para mi esta por encima sql server. ( es mi opinion ). Tambien probamos con mySql, pero en ese momento no tenia ni STORE PROCEDURE ni Transacciones, hoy creo que ya las tiene, igualmente es superior el postgres, mysql es bueno para hosting donde no se hacen muchos joins. Estuve evaluando la posibilidad de instalar CITRIX pero es muy costoso y desisti. Bueno entonces empezamos con postgres a pasar tablas simples primero, y fue muy bien, y muy simple de aplicar y hoy ya tenemos varias aplicaciones totalmente en postgres.. Tenes un ODBC y un OleDb muy facil de usar, nosotros usamos el ODBC. porque a mi en particular el Oledb nunca me gusto. Muy facil de hacer backup, restore, y te cuento una ves uno de mis programadores, se mando un delete en una tabla y gracias a que teniamos configurado que guarde los log pudimos recureperar todos las modificaciones que se habian hecho en la tabla y no perdimos nada, eso me dejo muy tranqui, hoy ya hicimos varios restore de tablas, las pasamos de server en server, y todo sale muy bien. Usamos una aplicaciones llamada EMS Manager for Postgres, que es mucho mas completa que el Enterprise manager de SQL Server. lo podes comprar o bajar de los torrent. Te conectas directamente con SQLStringConnect(), y SQLExec() . en internet hay muchos ejemplos. Tene es cuenta que empezamos con la version 7.1 de postgres y pasamos por la 8.0, 8.1 y hoy ya tenes la 8.3 que duplica la cantidad de transacciones por ms. y eso es muy importante simpre esta evolucionando. Tengo tablas de mas de 15 millones de registros, y anda muy bien. Hay un foro de postgres, yo tengo mas de 20.000 msg de todo, y hay mucha gente que labura en foxpro. Buena esto que te cuento es lo que vos tenes que ver, para elegir una solucion o tanto una base de datos Si te llegas a decidir por postgres, bajate de www..postrgres.org.ar la version 8.3.x para windows, o la plataforma que tengas, yo despues te paso la configuracion que necesitas hacer para que desde un punto de tu vpn, puedas acceder al servidor. Ah tambien podes probar de generar webservices, para que puedas ejecutarlos desde la vpn, ya que las ip generalmente son de diferentes subredes, y no podes correr los COM+ porque los usuarios no pertenecen al dominio central y no los podes validar, y w2003 es muy rompe en este tema, pero esot tambien funcionara cuando el volumen de informacion sea chico. Bueno espero haberte ayudado, cualquier cosa, no dudes en preguntarme asi si te puedo dar una mano que te ayude.. Ah y otra cosa que tenes que evaluar es si despues vas a tener alguna aplicacione web, nosotros tambien laburamos con php y este se comporta muy bien con postgres en linux, y en el futuro podes hasta pasar los servidores w2003 a linux y no tenes que tocar nada en tu aplicacion, porque la base es la misma, no cambia nada en donde este corriendo, en cambio si elegis SQL Server tenes que morir siempre con windows. Bueno espero haberte ayudado Saludos. ________________________________ Date: Thu, 24 Apr 2008 07:25:05 -0700 From: [EMAIL PROTECTED] Subject: [GUFA] SQL o qué? To: [email protected] Hola gente Tengo una aplicación en VFP7 que en redes locales anda sin problemas. Y resulta que ahora un cliente necesita acceder desde otros puntos para lo que en una máquina con win 2003 que oficia de servidor se armó un acceso por vpn y un escritorio remoto. El ER anda muy bien y a la velocidad del server, con exes en el remoto pero tienen problemas para imprimir y scanear (a las impresoras no las reconoce el win2003) por lo que lo imprimen en PDF y scanean con un pequeño exe local que les hice mapeado por VPN. Pero esto último es muy lento, lo del pdf y el acceso a las tablas por vpn (y eso que saqué casi todos los select para agilizar). En su momento dejé de lado los select pues me resultan más rápidos los seek y do while. Probé la aplicación completa local mapeada por VPN por el tema de las printers y es tremendamente lento. Por lo que me parece que debería migrar al SQL (no sé cuál, el SQL Server, el MySql) que me significaría volver a los sqlexec y/o vistas parametrizadas, no? Otra alternativa? Voy a tener más trabajo por mantenimiento/administración de archivos por el SQL? Bue, qué me sugieren? Muchas Gracias Estela ________________________________ Los referentes más importantes en compra/venta de autos se juntaron: Demotores y Yahoo!. Ahora comprar o vender tu auto es más fácil. Visitá http://ar.autos.yahoo.com/ ________________________________ Stop squinting -- view your photos on your TV. Learn more ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
