Anduve leyendo en las contribuciones de Harbour y por otros foros y
encontré esta documentación y acceso y wrapers a Postgres
http://www.vouch.info/harbour/index.html?hbpgsql.htm
En teoría TPQServer() sirve para conectarse a un servidor Postgres.
También hay ejemplos en la carpeta de contribuciones.
Están los fuentes a nivel de C.
Están las clases TPostgres.
Espero sirva de algo para contar con driver nativo y no tener que crear
conexiones ODBC en cada PC cliente.
Si puedo colaborar en algo más con todo gusto.
Saludos.
In order for this site to work correctly we need to store a small file (called a cookie) on your computer. Most every site in the world does this, however since the 25th of May 2011, by law we have to get your permission first. Please abandon the forum if you disagree.
Para que este foro funcione correctamente es necesario guardar un pequeño fichero (llamado cookie) en su ordenador. La mayoría de los sitios de Internet lo hacen, no obstante desde el 25 de Marzo de 2011 y por ley, necesitamos de su permiso con antelación. Abandone este foro si no está conforme.
Para que este foro funcione correctamente es necesario guardar un pequeño fichero (llamado cookie) en su ordenador. La mayoría de los sitios de Internet lo hacen, no obstante desde el 25 de Marzo de 2011 y por ley, necesitamos de su permiso con antelación. Abandone este foro si no está conforme.
Harbour y Postgres para José Gimenez
- Carlos Ortiz
- Mensajes: 873
- Registrado: Mié Jul 01, 2009 5:44 pm
- Ubicación: Argentina - Córdoba
- Contactar:
Harbour y Postgres para José Gimenez
Carlos,
> Anduve leyendo en las contribuciones de Harbour y por otros foros y
> encontré esta documentación y acceso y wrapers a Postgres
>
> http://www.vouch.info/harbour/index.html?hbpgsql.htm
>
> En teoría TPQServer() sirve para conectarse a un servidor Postgres.
> También hay ejemplos en la carpeta de contribuciones.
> Están los fuentes a nivel de C.
> Están las clases TPostgres.
>
> Espero sirva de algo para contar con driver nativo y no tener que
> crear conexiones ODBC en cada PC cliente.
>
> Si puedo colaborar en algo más con todo gusto.
El problema no es la conexión con psql. Nosotros ya teníamos un
datasource en funcionamiento desde 2009. El problema es que en psql no
es nada fácil obtener los metadatos necesarios para hacer funcionar los
datasets. Vamos, no es que no existan esos metadatos, sino que son
muchos y demasiado ambiguos, de modo que no existe una forma segura de
obtenerlos en todos los casos y que permitan, p.ej., identificar
inequívocamente una fila.
Para te te hagas una idea... en SQLite, existe una columna "virtual" en
todas las tablas llamada _RowId_, que nos permite identificar una fila
sin ningún tipo de error. Xailer utiliza esta información para poder
hacer UPDATEs en las tablas con total seguridad, sin afectar a múltiples
filas. En el caso de MySQL, no existe esa columna, pero sí es
relativamente fácil obtener la clave primaria de una tabla. Xailer
comprueba si en el query está contenida toda la clave primaria, y si es
así, entonces utiliza esa información para hacer los UPDATEs. Si la
clave primaria no está completa, entonces es imposible hacer UPDATEs de
forma segura, y por eso Xailer abre el query en modo solo-lectura.
Pero en el caso de PostgreSQL, esa información no está disponible de
forma clara, y lo más importante, no de forma 100% segura. Para obtener
la información que necesitamos, es necesario consultar varias tablas de
sistema, y siempre queda la posibilidad de no haber obtenido toda la
información relevante y poner en riesgo las operaciones de escritura en
la BD (UPDATEs, DELETEs, etc.). Esa fue la razón de que lo
abandonáramos, y te puedo asegurar que le dedicamos muchísimas horas de
trabajo, y no fue una decisión fácil. Bueno, la verdad es que en cuanto
llegamos a la conclusión de que no era 100% seguro, sí fue muy fácil
abandonarlo, porque por encima de las horas de trabajo está la seguridad
y fiabilidad de la herramienta.
En resumen, PostgreSQL se puede utilizar perfectamente como motor SQL,
escribiendo cada uno las sentencias SQL que necesite, a sabiendas de que
conoce prefectamente la estructura de la BD y sabe lo que tiene que
hacer. Pero los datasets son algo genérico. Tienen que funcionar sin
conocer de antemano la estructura de la BD, y necesitan obtener esa
información para poder hacer las operaciones de escritura de forma
segura. Si conoces una forma de obtener esa información y que sea 100%
segura, entonces no habría ningún problema en continuarlo.
No obstante, y como nota personal, considero que con la publicación de
una "librería de acceso cliente" para MariaDB, que además es compatible
con MySQL, y con licencia LGPL, ha cambiado mucho el panorama de las
BB.DD. para uso comercial. Antes, cuando la librería de acceso a MySQL
era GPL, quedaban pocas opciones: comprar una licencia de uso comercial
de MySQL a Oracle, usar PostgreSQL o usar FireBird (SQLite no cuenta
porque es un motor local). Pero ahora, se puede usar la librería de
acceso de MariaDB de forma totalmente gratuita desde un programa
comercial, y además atacando un servidor MariaDB o MySQL
indistintamente. Esto mismo ha hecho que en Xailer nos estemos
replanteando incluso hacer un datasource para FireBird.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
> Anduve leyendo en las contribuciones de Harbour y por otros foros y
> encontré esta documentación y acceso y wrapers a Postgres
>
> http://www.vouch.info/harbour/index.html?hbpgsql.htm
>
> En teoría TPQServer() sirve para conectarse a un servidor Postgres.
> También hay ejemplos en la carpeta de contribuciones.
> Están los fuentes a nivel de C.
> Están las clases TPostgres.
>
> Espero sirva de algo para contar con driver nativo y no tener que
> crear conexiones ODBC en cada PC cliente.
>
> Si puedo colaborar en algo más con todo gusto.
El problema no es la conexión con psql. Nosotros ya teníamos un
datasource en funcionamiento desde 2009. El problema es que en psql no
es nada fácil obtener los metadatos necesarios para hacer funcionar los
datasets. Vamos, no es que no existan esos metadatos, sino que son
muchos y demasiado ambiguos, de modo que no existe una forma segura de
obtenerlos en todos los casos y que permitan, p.ej., identificar
inequívocamente una fila.
Para te te hagas una idea... en SQLite, existe una columna "virtual" en
todas las tablas llamada _RowId_, que nos permite identificar una fila
sin ningún tipo de error. Xailer utiliza esta información para poder
hacer UPDATEs en las tablas con total seguridad, sin afectar a múltiples
filas. En el caso de MySQL, no existe esa columna, pero sí es
relativamente fácil obtener la clave primaria de una tabla. Xailer
comprueba si en el query está contenida toda la clave primaria, y si es
así, entonces utiliza esa información para hacer los UPDATEs. Si la
clave primaria no está completa, entonces es imposible hacer UPDATEs de
forma segura, y por eso Xailer abre el query en modo solo-lectura.
Pero en el caso de PostgreSQL, esa información no está disponible de
forma clara, y lo más importante, no de forma 100% segura. Para obtener
la información que necesitamos, es necesario consultar varias tablas de
sistema, y siempre queda la posibilidad de no haber obtenido toda la
información relevante y poner en riesgo las operaciones de escritura en
la BD (UPDATEs, DELETEs, etc.). Esa fue la razón de que lo
abandonáramos, y te puedo asegurar que le dedicamos muchísimas horas de
trabajo, y no fue una decisión fácil. Bueno, la verdad es que en cuanto
llegamos a la conclusión de que no era 100% seguro, sí fue muy fácil
abandonarlo, porque por encima de las horas de trabajo está la seguridad
y fiabilidad de la herramienta.
En resumen, PostgreSQL se puede utilizar perfectamente como motor SQL,
escribiendo cada uno las sentencias SQL que necesite, a sabiendas de que
conoce prefectamente la estructura de la BD y sabe lo que tiene que
hacer. Pero los datasets son algo genérico. Tienen que funcionar sin
conocer de antemano la estructura de la BD, y necesitan obtener esa
información para poder hacer las operaciones de escritura de forma
segura. Si conoces una forma de obtener esa información y que sea 100%
segura, entonces no habría ningún problema en continuarlo.
No obstante, y como nota personal, considero que con la publicación de
una "librería de acceso cliente" para MariaDB, que además es compatible
con MySQL, y con licencia LGPL, ha cambiado mucho el panorama de las
BB.DD. para uso comercial. Antes, cuando la librería de acceso a MySQL
era GPL, quedaban pocas opciones: comprar una licencia de uso comercial
de MySQL a Oracle, usar PostgreSQL o usar FireBird (SQLite no cuenta
porque es un motor local). Pero ahora, se puede usar la librería de
acceso de MariaDB de forma totalmente gratuita desde un programa
comercial, y además atacando un servidor MariaDB o MySQL
indistintamente. Esto mismo ha hecho que en Xailer nos estemos
replanteando incluso hacer un datasource para FireBird.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
- Carlos Ortiz
- Mensajes: 873
- Registrado: Mié Jul 01, 2009 5:44 pm
- Ubicación: Argentina - Córdoba
- Contactar:
Harbour y Postgres para José Gimenez
José antes que nada gracias por responder.
Entiendo lo de los dataset genéricos y me parece perfecto que sea así,
con esa capa intermedia se unifican los distintos formatos y para el
programador es transparente.
Como comentario, en Postgres se puede identificar inequívocamente una
fila por medio del campo OID que está presente en todas las tablas, es
cierto que se puede desactivar desde la versión 9.0 y no tener esa
característica pero dicho estado se puede consultar en la información
del esquema de la base de datos a la que estamos conectados y ver si
está usando los OIDS o nó y obligarlo a que esté activo, sino el dataset
será de solo lectura como a veces pasa con MySql.
Otro dato que está presente en todas las tablas es el CTID que ese no
se puede activar o desactivar (va activado lo uses o no)
Lo de MariaDB esta bueno y como no ser compatible si es producto de la
fragmentación de MySQL en proyectos como Drizzle, Percona, MariaDB y
OurDelta alla cuando salía la versión 5.
Disculpa que insista con temas relaciones a PostgreSQL pero dado los
sistemas que hacemos dónde hay mucha carga de transacciones, consultas
muy complejas y obligada integridad de los datos tenemos que usar algo
robusto y seguro, algo del estilo de Oracle y en ese nivel esta Postgres
y no MySql.
Si al menos pudiera tener una lib para enlazar y que haga la conexión al
motor y no tener que estar creando las conexiones ODBC en cada terminal
de cada cliente ya con eso me ayuda un montón.
Saludos.
Carlos Ortiz.
Entiendo lo de los dataset genéricos y me parece perfecto que sea así,
con esa capa intermedia se unifican los distintos formatos y para el
programador es transparente.
Como comentario, en Postgres se puede identificar inequívocamente una
fila por medio del campo OID que está presente en todas las tablas, es
cierto que se puede desactivar desde la versión 9.0 y no tener esa
característica pero dicho estado se puede consultar en la información
del esquema de la base de datos a la que estamos conectados y ver si
está usando los OIDS o nó y obligarlo a que esté activo, sino el dataset
será de solo lectura como a veces pasa con MySql.
Otro dato que está presente en todas las tablas es el CTID que ese no
se puede activar o desactivar (va activado lo uses o no)
Lo de MariaDB esta bueno y como no ser compatible si es producto de la
fragmentación de MySQL en proyectos como Drizzle, Percona, MariaDB y
OurDelta alla cuando salía la versión 5.
Disculpa que insista con temas relaciones a PostgreSQL pero dado los
sistemas que hacemos dónde hay mucha carga de transacciones, consultas
muy complejas y obligada integridad de los datos tenemos que usar algo
robusto y seguro, algo del estilo de Oracle y en ese nivel esta Postgres
y no MySql.
Si al menos pudiera tener una lib para enlazar y que haga la conexión al
motor y no tener que estar creando las conexiones ODBC en cada terminal
de cada cliente ya con eso me ayuda un montón.
Saludos.
Carlos Ortiz.
@dbfarma
www.dbfarma.com.ar
www.dbfarma.com.ar
Harbour y Postgres para José Gimenez
Carlos,
> José antes que nada gracias por responder.
>
> Entiendo lo de los dataset genéricos y me parece perfecto que sea así,
> con esa capa intermedia se unifican los distintos formatos y para el
> programador es transparente.
>
> Como comentario, en Postgres se puede identificar inequívocamente una
> fila por medio del campo OID que está presente en todas las tablas, es
> cierto que se puede desactivar desde la versión 9.0 y no tener esa
> característica pero dicho estado se puede consultar en la información
> del esquema de la base de datos a la que estamos conectados y ver si
> está usando los OIDS o nó y obligarlo a que esté activo, sino el
> dataset será de solo lectura como a veces pasa con MySql.
En su momento (fue hace años, y no recuerdo todos los detalles) lo
estuvimos viendo, y aunque en principio parecía que OID podía ayudar,
pronto vimos que no sólo OID no era obligatorio, sino que además estaba
siendo desaconsejado, y que por defecto las tablas se creaban sin OIDs.
Por lo tanto, si en vez de crear tú la BD, tienes que acceder a una BD
ya creada, pues no hay nada que hacer
> Otro dato que está presente en todas las tablas es el CTID que ese no
> se puede activar o desactivar (va activado lo uses o no)
No conocía o no recordaba este campo. Acabo de mirarlo, y seguramente lo
descartaríamos en su momento porque la documentación indica expresamente
que su valor puede cambiar. Pero parece que cambia cuando se ejecuta un
VACUUM, lo cual no lo invalida para lo que lo necesitamos. Será cuestión
de mirarlo más a fondo.
> Lo de MariaDB esta bueno y como no ser compatible si es producto de la
> fragmentación de MySQL en proyectos como Drizzle, Percona, MariaDB y
> OurDelta alla cuando salía la versión 5.
>
> Disculpa que insista con temas relaciones a PostgreSQL pero dado los
> sistemas que hacemos dónde hay mucha carga de transacciones, consultas
> muy complejas y obligada integridad de los datos tenemos que usar algo
> robusto y seguro, algo del estilo de Oracle y en ese nivel esta
> Postgres y no MySql.
No voy a entrar a valorar cual es mejor, sencillamente porque tampoco es
mi campo y no dispongo de los suficientes elementos de juicio. Pero hay
que reconocer que MySQL es un motor de BB.DD. muy popular y
perfectamente válido para casi todos los casos. Y MariaDB incluso mejora
el rendimiento con respecto a MySQL.
> Si al menos pudiera tener una lib para enlazar y que haga la conexión
> al motor y no tener que estar creando las conexiones ODBC en cada
> terminal de cada cliente ya con eso me ayuda un montón.
Bueno, el código está por ahí en algún sitio, no se llegó a tirar aunque
no se usa. No obstante, estamos hablando de 2009, y desde entonces han
cambiado muchas cosas, y más aún recientemente, con el paso a Harbour y
MinGW. Así que habría que adaptar todo ese código, y eso requiere
tiempo. No obstante, lo tendremos en cuenta y valoraremos si vale la
pena retomarlo.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
> José antes que nada gracias por responder.
>
> Entiendo lo de los dataset genéricos y me parece perfecto que sea así,
> con esa capa intermedia se unifican los distintos formatos y para el
> programador es transparente.
>
> Como comentario, en Postgres se puede identificar inequívocamente una
> fila por medio del campo OID que está presente en todas las tablas, es
> cierto que se puede desactivar desde la versión 9.0 y no tener esa
> característica pero dicho estado se puede consultar en la información
> del esquema de la base de datos a la que estamos conectados y ver si
> está usando los OIDS o nó y obligarlo a que esté activo, sino el
> dataset será de solo lectura como a veces pasa con MySql.
En su momento (fue hace años, y no recuerdo todos los detalles) lo
estuvimos viendo, y aunque en principio parecía que OID podía ayudar,
pronto vimos que no sólo OID no era obligatorio, sino que además estaba
siendo desaconsejado, y que por defecto las tablas se creaban sin OIDs.
Por lo tanto, si en vez de crear tú la BD, tienes que acceder a una BD
ya creada, pues no hay nada que hacer

> Otro dato que está presente en todas las tablas es el CTID que ese no
> se puede activar o desactivar (va activado lo uses o no)
No conocía o no recordaba este campo. Acabo de mirarlo, y seguramente lo
descartaríamos en su momento porque la documentación indica expresamente
que su valor puede cambiar. Pero parece que cambia cuando se ejecuta un
VACUUM, lo cual no lo invalida para lo que lo necesitamos. Será cuestión
de mirarlo más a fondo.
> Lo de MariaDB esta bueno y como no ser compatible si es producto de la
> fragmentación de MySQL en proyectos como Drizzle, Percona, MariaDB y
> OurDelta alla cuando salía la versión 5.
>
> Disculpa que insista con temas relaciones a PostgreSQL pero dado los
> sistemas que hacemos dónde hay mucha carga de transacciones, consultas
> muy complejas y obligada integridad de los datos tenemos que usar algo
> robusto y seguro, algo del estilo de Oracle y en ese nivel esta
> Postgres y no MySql.
No voy a entrar a valorar cual es mejor, sencillamente porque tampoco es
mi campo y no dispongo de los suficientes elementos de juicio. Pero hay
que reconocer que MySQL es un motor de BB.DD. muy popular y
perfectamente válido para casi todos los casos. Y MariaDB incluso mejora
el rendimiento con respecto a MySQL.
> Si al menos pudiera tener una lib para enlazar y que haga la conexión
> al motor y no tener que estar creando las conexiones ODBC en cada
> terminal de cada cliente ya con eso me ayuda un montón.
Bueno, el código está por ahí en algún sitio, no se llegó a tirar aunque
no se usa. No obstante, estamos hablando de 2009, y desde entonces han
cambiado muchas cosas, y más aún recientemente, con el paso a Harbour y
MinGW. Así que habría que adaptar todo ese código, y eso requiere
tiempo. No obstante, lo tendremos en cuenta y valoraremos si vale la
pena retomarlo.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
- Carlos Ortiz
- Mensajes: 873
- Registrado: Mié Jul 01, 2009 5:44 pm
- Ubicación: Argentina - Córdoba
- Contactar:
Harbour y Postgres para José Gimenez
Entendido y gracias una vez más!
PD: Hace muchos años que estamos usando Postgres y MySql, en lo que
podemos colaborar será con todo gusto.
Saludos.
PD: Hace muchos años que estamos usando Postgres y MySql, en lo que
podemos colaborar será con todo gusto.
Saludos.
@dbfarma
www.dbfarma.com.ar
www.dbfarma.com.ar