FiveTech Support Forums

Uso las Dbf y en un programa personal dolphin

Luis

Perfecto...

Cuanta más información tengamos mas conclusiones podremos sacar así que os animo a seguir!!!
8)

Hola

• Actualmente usamos Mariadb
• Para nuevos proyectos seguiriamos usando Mariadb y/o postgresql
• Documentacion, soporte, velocidad, simplicidad de uso, compatibilidad de la sintaxis con Ado

Saludos desde Osorno, Chile

Lautaro

Buenos dias Lautaro ha puesto el tema de que sea como ADO es por la simplicidad de los objetos eso hasta yo que soy neofito lo he podido usar se agradecerian clases similaras para coneccion, recordset etc gracias Wilson

Hola Lautaro, no he entendido muy si estás usando ADO o una clase que emula a las de ADO.

Creo que ADO es muy lento dependiendo de para qué se use...
:cry:

Hola Manuel ....

Uso 95% MySql 5% Dbf

Con Eagle1

Aprovecho el momento Manuel, te envie un correito s tu gmail.. , espero tu respuesta.

Gracias estimado Lubin

wilsongamboa wrote:

Buenos dias Lautaro ha puesto el tema de que sea como ADO es por la simplicidad de los objetos eso hasta yo que soy neofito lo he podido usar se agradecerian clases similaras para coneccion, recordset etc
gracias
Wilson

Wilson,
Usamos ado por lo simple, despues de usar odbc fue el siguiente paso.

Tenemos un par de clases que nos simplifican la conexion y el uso de los recordsets.

Si quieres te las puedo compartir.

Un saludo

xmanuel wrote:

Hola Lautaro, no he entendido muy si estás usando ADO o una clase que emula a las de ADO.

Creo que ADO es muy lento dependiendo de para qué se use...
:cry:

Hola,

Usamos ado, con algunas clases que le pusimos encima para que sea mas facil su uso, pero es ado, antes de eso usabamos odbc, asi que hicimos unas clases para no tener que reescribir el codigo de la aplicacion.

En nuestra experiencia, puede ser un poco mas lento, pero administra muy bien la memoria, cuando son dataset extensos y algunas otras cosillas por lo que sumando y restando , ado es una muy buena herramienta cuando programas en windows.

Saludos,
Lautaro

Se agradece mucho Lautaro mi mail wilsonPUNTOjosenetARROBAgmailPUNTOcom gracias Wilson

Wilson,

I have to smile a little.

You carefully wrote:

wilsonPUNTOjosenetARROBAgmailPUNTOcom

— like a classic anti-spam ninja move from the early internet days.

And then two lines below you posted:

Wilson.josenet@gmail.com

Full resolution. No decoding required. No puzzle. No protection.

That’s not hacking.
That’s self-service.

And here comes the interesting part:

With DBF this never happens.

Because in the DBF world people actually know their structure, know their fields, know their indexes — and they don’t accidentally open doors they just tried to close.

It’s almost a philosophical proof:

When you understand your data model, you don’t leak your data model.

Consider this Exhibit A in the case of “Why controlled architectures matter.”

Best regards,
Otto - Now on PostgreSQL

Perdona Lubin!!!

Sí vi el correo y nuestro común amigo Félix me lo comentó. Este fin de semana estuve fuera de casa. Me podré sin falta el de esta semana...

Gracias por tu paciencia!!!!

TABLA 1 — ¿Qué bases de datos usas actualmente?
(respuesta múltiple, 21 participantes)

Base de cálculo: 21 participantes únicos

TABLA 2 — ¿Qué base de datos considerarías para tu
próximo proyecto o migración? (máx. 2 opciones)

TABLA 3 — Características MÁS IMPORTANTES en una
librería de acceso a BD (máx. 3 opciones)

TABLA 4 — ¿Qué te frena para migrar? (opcional)

🚀 ¿No es hora de que Harbour tenga una librería de bases de datos a la altura?

Seamos honestos: uno de los puntos débiles que más frena el crecimiento de Harbour es la falta de una solución moderna, unificada y nativa para acceder a bases de datos. Dependemos de soluciones parciales, desactualizadas o de terceros que no siempre se mantienen al día. Eso tiene que cambiar.

La idea es clara y ambiciosa: una única librería, una única API, una única forma de trabajar, independientemente del motor de base de datos que haya detrás. Sin tener que reaprender nada al cambiar de motor. Sin código específico para cada BBDD. Sin sorpresas. Tu aplicación habla con la librería, y la librería habla con la base de datos. Así de simple.

¿Necesitas migrar de SQLite a PostgreSQL? Cambias una línea de configuración. ¿Tu cliente usa SQL Server y tú desarrollas con MariaDB? No importa. El código es el mismo. Siempre.

Estos serían los motores soportados:

• MySQL / MariaDB — El dúo más popular del mundo open source

• PostgreSQL — Potencia y fiabilidad empresarial

• SQL Server — Imprescindible en entornos corporativos

• Oracle — El gigante de las bases de datos empresariales

• SQLite / SQLCipher / SQLiteMC — Ligero, embebido y con cifrado

• Firebird / InterBase — Un clásico muy querido en nuestra comunidad

• ODBC — Puerta abierta a cualquier otro motor

Una librería así no solo facilitaría el trabajo diario de cada desarrollador Harbour, sino que abriría la puerta a proyectos más ambiciosos, atraería nuevos desarrolladores a la comunidad y demostraría que Harbour sigue siendo una plataforma vigente y competitiva.

Estoy dispuesto a desarrollar esta librería, pero necesito vuestra financiación para hacerlo realidad.

Si usas Harbour profesionalmente, sabes perfectamente el valor que algo así tendría para tu día a día y para tus clientes. Una pequeña aportación de cada uno de nosotros puede convertirse en una herramienta que nos beneficie a todos.

¿Estáis dispuestos a apoyar económicamente este proyecto? Responded en el hilo o contactadme en privado y organizamos cómo canalizarlo. Entre todos podemos hacerlo posible. 💬

Formas de interactuar con los datos
Existen tres formas principales de trabajar con datos en Harbour, que van desde el control total del motor hasta la abstracción completa del lenguaje:
1. Acceso Directo (Nivel de API)
Consiste en utilizar clases que actúan como "wrappers" (envoltorios) de las API nativas en C de cada motor (MySQL, PostgreSQL, SQLite, Oracle, etc.). Es el método más rápido y potente, pero requiere escribir código específico para cada base de datos, lo que reduce la portabilidad.
2. ORM (Object-Relational Mapping)
Técnica que permite interactuar con la base de datos tratando las tablas como objetos y las filas como instancias de clases. En lugar de escribir comandos de base de datos directamente, se manipulan objetos del lenguaje, lo que resulta en un código más legible y mantenible.
3. RDD (Replaceable Database Drivers)
Es la forma más característica de Harbour, heredada de Clipper. La gran ventaja de HDBC es que permite usar los comandos y funciones tradicionales del estilo RDD para acceder y manipular bases de datos SQL (MySQL, PostgreSQL, SQLite, Oracle, etc.), sin necesidad de escribir sentencias SQL explícitas. El código resulta familiar para cualquier desarrollador con experiencia en Clipper/Harbour, pero trabajando contra un motor de base de datos moderno.

• []Navegación:

  Code: Select all Collapse

  DbGoTop(), DbGoBottom(), DbSkip(), GO TOP, SKIP +1

  []Control de áreas:

  Code: Select all Collapse

  DbSelectArea(), DbCloseArea(), SELECT 0, USE ... SHARED

  []Manipulación de datos:

  Code: Select all Collapse

  DbAppend(), DbDelete(), DbRecall(), APPEND BLANK, DELETE, REPLACE field WITH value

  []Búsquedas e índices:

  Code: Select all Collapse

  DbSeek(), DbSetIndex(), OrdSetFocus(), SEEK, SET ORDER TO

• Acceso a campos:

  Code: Select all Collapse

  FieldGet(n), FieldPut(n, valor), ALIAS->Campo

Los tres enfoques no son excluyentes: es posible combinarlos según las necesidades del proyecto.

xmanuel wrote:

🚀 ¿No es hora de que Harbour tenga una librería de bases de datos a la altura?

Seamos honestos: uno de los puntos débiles que más frena el crecimiento de Harbour es la falta de una solución moderna, unificada y nativa para acceder a bases de datos. Dependemos de soluciones parciales, desactualizadas o de terceros que no siempre se mantienen al día. Eso tiene que cambiar.

La idea es clara y ambiciosa: una única librería, una única API, una única forma de trabajar, independientemente del motor de base de datos que haya detrás. Sin tener que reaprender nada al cambiar de motor. Sin código específico para cada BBDD. Sin sorpresas. Tu aplicación habla con la librería, y la librería habla con la base de datos. Así de simple.

¿Necesitas migrar de SQLite a PostgreSQL? Cambias una línea de configuración. ¿Tu cliente usa SQL Server y tú desarrollas con MariaDB? No importa. El código es el mismo. Siempre.

Estos serían los motores soportados:

• MySQL / MariaDB — El dúo más popular del mundo open source

• PostgreSQL — Potencia y fiabilidad empresarial

• SQL Server — Imprescindible en entornos corporativos

• Oracle — El gigante de las bases de datos empresariales

• SQLite / SQLCipher / SQLiteMC — Ligero, embebido y con cifrado

• Firebird / InterBase — Un clásico muy querido en nuestra comunidad

• ODBC — Puerta abierta a cualquier otro motor

Una librería así no solo facilitaría el trabajo diario de cada desarrollador Harbour, sino que abriría la puerta a proyectos más ambiciosos, atraería nuevos desarrolladores a la comunidad y demostraría que Harbour sigue siendo una plataforma vigente y competitiva.

Estoy dispuesto a desarrollar esta librería, pero necesito vuestra financiación para hacerlo realidad.

Si usas Harbour profesionalmente, sabes perfectamente el valor que algo así tendría para tu día a día y para tus clientes. Una pequeña aportación de cada uno de nosotros puede convertirse en una herramienta que nos beneficie a todos.

¿Estáis dispuestos a apoyar económicamente este proyecto? Responded en el hilo o contactadme en privado y organizamos cómo canalizarlo. Entre todos podemos hacerlo posible. 💬

Hola Manu, se ve interesante tu propuesta.
Como sabes, trabajo con Eagle1 desde hace muchos años, y me ha ayudado a separar la capa de datos en mi codigo, y utilizo bastante la forma de correr la consulta a MySQL y trabajar las respuestas con FieldGet() o xFieldGet(), y lo unico que he querido siempre es, no depender de la LibMySQL.DLL

Esta librería utilizaría siempre DLL's para conectarse entre los motores de bases de datos?

Saludos cordiales.

Carlos