Xailer & OZ Software

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.

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

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.

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

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.