@ 10,10 XBROWSE oBrw ;
OF oDlg SIZE 250,180 PIXEL ;
ALIAS "TEMPOR" ;
AUTOCOLS AUTOSORT FOOTERS LINES CELL
Podrías ser tan amable de definirlo en la forma convencional usada anteriormente (TXBrowse():New(), etc.) para que podamos compilarlo sin modificaciones quienes tenemos versiones anteriores?
Mis conocimientos usando compiladores Clipper son muy basicos, el SQLWIN me parece un muy buen proyecto y quisiera hacerte 3 consultas, espero me puedas ayudar:
1. Que diferencia tiene el SQLWin que se está desarrollando con la versión comercial, me refiero a la funcionalidad.
2. La interface que existe con el SQL a traves del manejador es un simulador de DBF's porque veo que crea tablas de indices para poder administrarlo independientemente del motor de base de datos. Es algo que no entiendo muy bien.
3. Con este proyecto se podrá escribir sentencias DDL para interactuar directamente con la base de datos.
Esas serían todas mis consultas, desde ya, muchas gracias por leer estas lineas.
SQLWIN de momento es solo un prototipo que pretende mostrar la forma de crear un RDD que traduzca las típicas funciones Db...() en sentencias SQL.
Es decir, por ahora no es usable. Solo puede servirles a quienes quieran aprender acerca de la creación de este RDD y/o quieran participar en el proyecto. Es un proyecto de código libre. Cualquiera puede participar, y evolucionará si hay usuarios que se interesen y participen en él. Igual que en cualquier otro proyecto de software libre.
Los usuarios que necesiten un RDD de estas características ya, y que no tengan tiempo para esperar y/o colaborar, lo mejor que pueden hacer es comprar uno comercial, tipo SQLRDD.
En lo particular veo a FiveWin y SQLRDD como la pareja ideal que todos buscamos para continuar usando xBase sin cambios significativos y poder acceder a practicamente cualquier Gestor SQL.
Acabo de instalar una de mis aplicaciones para una empresa con tres sitios remotos (Oficinas, Planta y Almacenes) donde están enlazados unos 60 equipos a un servidor con MySQL y verdaderamente me sorprende que no se ha presentado una sola falla (de las comunes con DBFs) en mas de dos semanas de operación. Antes había que reindexar y reprocesar información al menos una vez al día.
En esta aplicación no he tenido la necesidad de usar una sola sentencia SQL, ni trigers, cursores, recordsets; nada de eso. Todo, absolutamente todo el código es xBase (Clipper o xHarbour) con FiveWin y puede trabajar DBFs y/o tablas SQL de manera indistinta.
Creo que bien podemos avanzar con el prototipo SQLWIN. Ya con el conocimiento actual veré si en mis tiempos libres puedo aportar algo para avanzar en el desarrollo de esta herramienta.
SQLRDD es un buen producto. pero tiene 2 problemas que a MI PARECER no lo hacen viable.
1.- Me enfrente a un trabajo donde las DB (MYSQL) ya estaban creadas y pobladas con varios millones de registros, pues bien, tenia la clave de usuario para acceder, modificar y eliminar registros, pero no para crear tablas, AHI SQLRDD trono, al hablar con el administrador de la DB y solicitarle autorizacion pues mi LIB necesitaba crear tablas de uso interno y modificar la estructura de la DB, pues bien, un rotundo NO, y la frase fue explicita ... ¿ Acaso tu lenguaje no permite trabajar con la DB tal cual esta... si hasta VISUAL lo hace sin interferir en la estructura de los datos ?
2.- Usar un RDD para acceder a SQL, y acceder al INMENSO PODER de sql, "sin usar SQL".. pues no... ni creo que se puedan manejar bien las STORED PROCEDURES ni mucho menos.. por los post en xhb que he leido...
Yo lo probe con la version que compre hace dos años y algo, y dentro de sus posibilidades encontre mejor, mas rapido y eficiente el uso de ADO, y hasta diria que mas compatible entre Postgress, Oracle, Mysql, SQL Server, pues con los 4 lo probe y solo cambie el string de conexion.... y lo mejor pude usar SQL a su maxima expresion, con joins, stored procedures, triggers etc etc.. aunque solo fueron pruebas.
Y no veo cual es la ventaja de poder usar con el mismo exe MYSQL y las DBF... SQL sera siempre mejor y mas poderoso, y creo que SQLRDD lo que hace es ponerle un freno y bajarlo a la categoria de dbf.
Para mi.. lo mejor es tener un RDD de SQL lo menos invasivo posible, que no necesite alterar la estructura de los datos, por si me topo con algo ya creado o administrado por terceros, como pueden ser las instituciones gubernamentales, internacionales, grandes compañias, tiendas por departamento, instituciones de educacion como Universidades etc etc.
La idea de SQLWIN, es buenisima, si se respetan estas 3 cosas.
- 100 % compatible con SQL, aunque parezca estupido, pero si voy a acceder a SQL, que sea con TODO.
- Usar la misma bateria de comandos y funciones a las que estamos acostumbrados para el desarrollo rapido o la reutilizacion de codigo.
- Soporte a los menos de las 4 Grandes ( Sql Server, Mysql, Postgress, Oracle )
Yo me he alejado del desarrollo de clases o rutinas para conectarme a SQL ( ADOBASE esta en un estado de hibernacion ) por una gran cantidad de trabajo que me obligo a desarrollar con DBFCDX's producto de compatibilidad con antiguas aplicaciones y demases... pero ya estoy terminando y veo que se puede hacer algo bueno, apenas tenga tiempo y ideas claras vuelvo con todo, no se si para ayudar a SQLWIN o terminar mi ADOBASE.. pero definitivamente SQL es el camino a seguir.
My 2,5 cents
Desde Chile
Adolfo
Ji,ji,ji... buena la cosa... "all you need is code"
.
Ji,ji,ji... buena la cosa... "all you need is code"