Antonio.. tienes un ejemplo completo de mysql y xharbour

[leandro]

Antonio como vas, espero que bien.

Necesito un favor, lo que pasa es que por ahi buscando encontre un manual para mysql y habour. De causalidad no tienes uno para xhabour o me sirve el mismo?

De antemano gracias

[Antonio Linares]

Leandro,

Debería servirte el mismo. De todas formas el "gurú" del MySQL es Manú Expósito.

[JMFS-D]

Puedes utilizar Eagle1 y Condor1 de Manuel Expoxito.

Lo puedes encontar en:

http://es.groups.yahoo.com/group/eagle1/
http://es.groups.yahoo.com/group/condor1/

Saludos, José Mª

[jlcapel]

Leandro,

Otra opción que puedes valorar es usar ADO para acceder a MySql.

Saludos,
José Luis Capel
PD: Ver http://fivetechsoft.com/forums/viewtopi ... =5287#5287

[leandro]

jlcapel, como vas?

Perdon la ignorancia, pero me puedes explicar un poco mas que es ADO y cuales son sus ventajas?

[R.F.]

No soy JL Capel, pero "algo" se de esto:

1) ADO = Activex Data Objects, un estandar de windows que te permite accesar a datos SQL utilizando componentes OLE

2) La ventaja, no necesitas configurar nada excepto el "ADO Provider", que en realidad es un componente ODBC muy simple de instalar.

3) ADO te provee de una forma estandar de acceder a los datos, sin importar que base de datos utilices, MySQL, SQL Server, Oracle, Informix, ADS etc. El mismo juego de metodos ADO funciona para cualquier base de datos.

4) ADO trabaja con 3 objetos basicos: Conexion, Comando y RecordSet, todos accesibles desde OLE con (x)Harbour.

5) Un objeto RecordSet es muy similar a un objeto TDBF de FW, asi todas las operaciones sobre un grupo de datos son realizadas de manera rapida sin necesidad de ejecutar comandos SQL sobre una tabla.

Este es un ejemplo basico de conexion ADO con MySQL:

Code: Select all

   

/* creamos el objeto conexion */
oCon:=toleauto():new("adodb.connection")

/* conectamos con el servidor de base de datos de MySQL */
 oCon:OPEN("DRIVER={MySQL ODBC 3.51 DRIVER};SERVER=192.168.2.101;DATABASE=garis;UID=root;PWD=18167231")


/* creamos un objeto comando para ejecutar los queries */
 oSql:=toleauto():new("adodb.command")

/* "conectamos" el objeto comando con la conexion previamente creada*/
oSql:ActiveConnection(oCon)

/* Creamos el Query SQL en la DATA CommandText*/
 oSql:CommandText:="Select * from B3000 where nomar like '%CHICO%'"

/* Ejecutamos el Query, el resultado del query queda guardado en otro objeto tipo "recordset" */
oDatos:=oSql:Execute()

/* ¿ cuantos renglones trajo de regreso el query ?*/
? STR(oDatos:RecordCount())

/* ¿ cuantas Columnas trajo de regreso el query ? */
? STR(oDatos:Fields:Count())

/* Vamos a volcar todos los datos retornados por el query en un array de (x) Harbour*/

aDatos := {}

oDatos:MoveFirst() // equivale a GO TOP en un DBF

do while .not. oDatos:EOF()
   AADD(aDatos, {oDatos:Fields(0):value,;
                          oDatos:Fields(1):value,;
                          oDatos:Fields(2):value,;
                          oDatos:Fields(3):value})
     oDatos:MoveNext() // equivale un SKIP en un DBF
enddo

[Carlos Sincuir]

Rene,
Donde puedo encontrar mas información de los comandos, varaibles,etc., de ADO, ej:

Code: Select all

oSql:CommandText:=...
oDatos:=oSql:Execute() 
oDatos:RecordCount()
oDatos:Fields:Count()
oDatos:MoveFirst()
oDatos:Fields(0):value...

etc.

Saludos,

Carlos Sincuir

[Hernan Diego Ceccarelli]

Hola
Me interesaria ver un lindo ejemplo de un ABM con ADO, eso, basicamente una tabla inicial de presentacion, modificaciones alta y bajas, como ir refrescando el recordset o existe necesidad de crear otro ?
Y creo que se podria browsear DIRECTAMENTE el recordset de ADO sin necesidad de incorporar un array de por medio, mas aun si quiero browsear una base de datos de millones de registros, me quedaria sin memoria

Salu2

[YamilBracho]

Algo que hay que agregar es que necesitas instalar el MyODBC que lo descargas gratis del website de MySQL

[R.F.]

Hola
Me interesaria ver un lindo ejemplo de un ABM con ADO, eso, basicamente una tabla inicial de presentacion, modificaciones alta y bajas, como ir refrescando el recordset o existe necesidad de crear otro ?
Y creo que se podria browsear DIRECTAMENTE el recordset de ADO sin necesidad de incorporar un array de por medio, mas aun si quiero browsear una base de datos de millones de registros, me quedaria sin memoria

Salu2

Hernan:

Una de las cosas que hay que quitarnos de la cabeza cuando trabajamos con SQL, es ell modelo de BROWSES de los lenguajes xBase, aqui no se trata de poner una tabla en un browse y darle doble click a un registro para luego traerte la informacion de dicho registro.

Ten en cuenta que el modelo SQL es un modelo que se invento a finales de los 60's y no ha cambiado mucho desde entonces.

La idea principal del SQL es realizar busquedas que reporten LA MENOR CANTIDAD DE DATOS POSIBLES, es decir, en un sistema por ejemplo de personal, no pones un browse con TODOS los nombres y claves de los trabajadores, le das doble click a un registro y te traes sus datos, mas bien, tienes un GET, le das la clave del trabajador o algun dato que te permita recuperar la informacion, y el programa te devolvera un grupo reducido de datos basados en tu criterio de busqueda, por eso se llama SQL = Structured Query Language o Lenguaje Estructurado de BUSQUEDAS.

Este modelo fue diseñado asi desde un princpio, y aunque es perfectamente posible traerte una base de datos de hasta 4 millones de registros (con (x)Harbour) y meterla en un array, pues en realidad es una tonteria hacerlo siendo que bajo el modelo SQL se busca tener la menor cantidad de datos posible.

Ahora bien, el volcado de datos a un array lo hice por una deformacion profesional de hace muuucho tiempo, te explico:

Antes de trabajar con ADO, era necesario el uso de ODBC, (ahora también pero ADO simplifica el modelo), cuando trabajas con ODBC, todos tus Queries quedan atrapados en un "CURSOR", este cursor es un area de memoria donde reside el resultado del query ejecutado, la unica forma de compatibilizar eso con FiveWin, era descargar el resultado de dicho Query a un DBF temporal o a un Array para poder visualizar los datos.

Actualmente, gracias al modelo ADO, tu puedes browsear directamente sobre el RecordSet, simplemente define las columnas de tu browse como datas oRecordSet:Fields(x):value, define un bloque de código :Bskip para moverte sobre los registros del RecordSet, y asigna la data :bLogicLen a RecordSee:RecordCount() y te ahorras la molestia de pasar por el array.

Para la actualizacion de datos tiene distintos metodos del record set que se encargan de ellos, eso si, dependen del tipo de cursor que estes utilizando, tambien es importante recordar que para este inviento de la actualizacion directa del RecordSet funcione, es necesario haber hecho un buen diseño de la base de datos, que incorpore el uso de llaves primarias, relaciones e integridad referencial.

[Joel Andujo]

Actualmente, gracias al modelo ADO, tu puedes browsear directamente sobre el RecordSet, simplemente define las columnas de tu browse como datas oRecordSet:Fields(x):value, define un bloque de código :Bskip para moverte sobre los registros del RecordSet, y asigna la data :bLogicLen a RecordSee:RecordCount() y te ahorras la molestia de pasar por el array.

Un pequeño ejemplo de esto seria maravilloso master

Saludos
Joel Andujo

[R.F.]

Jose Luis Capel hizo unos ejemplos muy interesantes, visita su blog:

http://www.capelblog.com/?p=58

[Hernan Diego Ceccarelli]

Rene,
Muchas gracias, has sido muy explicativo. Los modelos SQL nos dan rapidez de consulta, seguridad y C/S, pero nos limitan la "intuitividad" de la aplicacion, es decir, no se concibe un abm intuitivo de algo sin un browse, en ese sentido vamos para atras.

Salu2

[R.F.]

Rene,
Muchas gracias, has sido muy explicativo. Los modelos SQL nos dan rapidez de consulta, seguridad y C/S, pero nos limitan la "intuitividad" de la aplicacion, es decir, no se concibe un abm intuitivo de algo sin un browse, en ese sentido vamos para atras.

Salu2

Asi es, ademas de que el concepto de "bloqueo" de registros no existe, un SQL plantea bloqueos "optimistas", es decir, si dos personas estan visualizando la misma informacion, y los dos deciden modificarla, prevaleceran _ que haga LA ULTIMA persona.

Tampoco existe la actualización de las vistas en linea, es decir, si dos personas estan visualizando la misma informacion, y un tercero altera alguno de los datos visualizados por los otros dos, ambos deberan de "refrescar" la vista de datos para tener acceso a las ultimas modificaciones.

El modelo XBase de finales de los 70 prometia superar algunas de las espectatvias de lo que eran los modelos SQL de los 60's, ahora, el modelo ADO pretende copiar lo mismo que hizo el Xbase en su momento, creando objetos RecordSet (que se pudieran comparara con DBFs), y trabajando sobre esos objetos (como si fuesen campos de una DBF), con instrucciones muy similares a las que en su momento tuvo dBase.

El modelo ADO pretende darte en "background" un modelo de bloqueo y actualizacion en linea, como lo daba en su momento el modelo Xbase, el gran problema con el que se en encuentra ADO es que la arquitectura sQL no esta pensada como si fuera XBase.

Por otro lado, solo los gestores de bases de datos "potentes" como Oracle, SQL Server, Sybase y otros, te dan los componentes necesarios para lo que ADO pretende hacer, si bien MySQL, Postgre, o FireBird te presentan la funcionalidad de un SQL, nunca tendran las prestaciones de un SQL de paga, por algo cuestan lo que cuestan.

Si yo siempre he dicho, que lo unico que le hace falta al Xbase para ser perfecto era una herramienta que lo manejara como Gestor de Base de Datos Relacional, y ADS lo hace, con lo cual.....