Consultas a MariaDB

[Enrique]

Hola a todos. Estoy tratando de pasar  de DBF a MariaDB. Con la ayuda de este gran grupo intentando salir adelante, con sus concejos y ayuda.

Tengo dos dudas:

1. Cuando realizo una consulta en un formulario , cada vez que  realice una consulta (botón combo, Check, etc), me tengo que conectar a la base de datos. O Bien una vez realizada, puedo trabajar con el comando select normalmente en el mismo formulario?.

2-  Me gustaría tener una base de datos en un hosting y realizar pruebas remotamente poder conectarme a esa base de datos.

a.- Que debo contemplar y solicitar para el alojamiento en un hosting.

b.- Como me conecto a esa base de datos remotamente.

Por ahora, me conecto a la base de datos de mi equipo y siguiendo los concejos de los colegas de mayor experiencia, en la cual aclaran la conveniencia de ir olvidando las DBF (que me ciento muy cómodo con ellas), pero tengo que dejarlas.

Muchas Gracias quien me pueda aconsejar .

[HernanCano]

Duda #1:

Puedes usar ambas formas, la que mejor se adapte a tu forma de programar.

Una se podría llamar "modo conectado" y el otro "modo desconectado".

"Modo conectado" es cuando haces la conexión la primera vez, y dejas la conexión para que se puedan utilizar otros SELECT-SQL (o cualq otro comando SQL) más adelante al motor.

"Modo desconectado" es cuando haces la conexión la primera vez, ejecutas un SELECT-SQL (o cualq otro comando SQL) hacia el motor y cierras la conexión; si necesitas ejecutar otros comandos SQL al motor, debes volver a ejecutar la conexión antes de ejecutar el comando SQL.

Si bien la explicación del "modo desconectado" luce aburridora (repetir la conexión), es una forma recomendada de trabajar con motores de datos relacionales, pues dejar la conexión abierta mucho tiempo ("sin usar") puede presentar ciertos tipos de problemas.... algo malucos de explicar....

Sólo te digo que es una "buena práctica de programación" (no sólo con VFP), y  la experiencia nos lleva a ello: a darles ese tipo de indicación a los primerizos.

Pero evidentemente no es camisa de fuerza. Puedes usar el "modo conectado" y si se te presentan problemas quizá la experiencia te lo demuestre.

Duda #2:

Como parte del proceso de contratar un hosting, se te dará unos datos que llamaremos "de autenticación", lo que ya conoces como autenticación: nombre de usuario y contraseña; claro que no es lo único: se te dará también una (posiblemente) IP, un  nombre de base de datos, etc.... Lo que te den, deberá ser usado para la autenticación (no compartas datos reales: sí el nombre de los parámetros, pero no el contenido de ellos...o cuando los compartas, cámbialos por una serie de XXXXXX o asteriscos, en mayu/minu es indiferente).

Para conectarte a esa base de datos remotamente lo haces igual que te conectas ahora en tus pruebas, sólo cambiando el nombre del servidor, el usuario, la contraseña, la base de datos ---si es que te dan un nombre de base de datos-,... como te dije: usa lo que te dan.... en la cadena de conexión.

[Edwin Duran]

no se que estas usando para trabar con MariaDb, en mi caso utilizo la Clase SqlData, para trabajar con diferentes motores, también existe FoxyDb, tengo dos aplicaciones pequeñas en web hosting compartido https://my.interserver.net/ 

pago como 80 dólares mensuales, con el dominio y certificado, utilizando SQLServer Express 2019, soporta Tiene MariaDB, los servicios de linux soportan muchas cosas

[Enrique]

Muchas Gracias por sus concejos. Los tomare en cuenta para continuar en este  proceso de pasar de DBF a MariaDB. 

[Germán Fabricio Valdez]

hola enrique

lo que queres hacer , tiene su complejidad.

usa sqldata2 para mariadb es FULL FREE, 

sqldata2 funciona basicamente asi

haces una consulta al servidor en el metodo load, y se crea un cursor temporal

crea indices.

luego tu programa casi no tenes que hacer grandes cambios, ya que son dbf

luego colocas un boton grabar, y los cambios del cursor se hacen en el servidor

Todo lo que deben tener presente al trabajar con motores de base de datos, cliente-servidor. para no naufragar

*conectar al servidor remoto: local, internet, hosting

*si no se puede conectar, reintentara automaticamente, antes de cualquier operacion y no dara error de conexion.

*cada vez que se conecta al servidor, se deben enviar distintas instrucciones nuevamente

*a veces la conexion se muestra activa, pero no lo esta. y hay que reconectar

*mantener la conexion activa, impidiendo que el servidor corte la conexion por inactividad. durante 20 minutos, y luego cerrar la conexion.

*apertura y cierre de conexion por grupo de instrucciones.

*envio para alta velocidad: eliminar , actualizar, insertar, de a 100 registros, al servidor y operar alli. en lugar de instruccion por instruccion

*si se mantiene la conexion desde que la abren al comienzo del programa, y lo cierran al finalizar el programa. empieza a ponerse lento el servidor y los demas usuarios

*compatibilidad con los distintos tipos de campos

*manejo de fechas nulas, en lugar de fechas en blanco (da error al grabar)

*manejo de transacciones: se graban todas las tablas relacionadas, y si hay error no se graba ninguna: ejemplo cliente, detalle

*manejo de campos llaves:  id, idcliente, codcliente, "fecha,prefijo,numero" de distintas tablas. adaptando a otras tablas de distintas bases de datos que no usan id

*crear columnas adicionales para calculos, que no se deben grabar en la tabla del servidor

*trabajar con imagenes, o archivos, almacenados en campos de la tabla, en el servidor

*regular el tiempo de espera para que una instruccion se complete

*regular el tiempo de espera de una conexion al servidor.

*poder conectarse a distintos servidores a la vez.

*administrar errores. 

*hay funciones no documentadas de vfp.

*adaptarse a las distintas bases de datos mas usadas: sql server, mysql, mariadb, firebird, postgresql, oracle. automaticamente

*leer tablas maestro desde el servidor remoto (para llenar combos), y grabarlo en pc local. y la proxima vez que se ingresa al formulario, no vuelve a cargar todo nuevamente.

*los hosting, no son todos iguales. hay distintos modos de grabacion para adaptarse

*concurrencia, conectividad, optimización, seguridad.  

*trabajar con campos ID (identity), para relacionar tablas, madre-hija, madre-madrehija-hija,  madre-madre-madrehija-hija.

*trabajar con instrucciones multiples, para enviar de una sola vez al servidor

Lo que hay que saber.  Que cuando se contrata un proveedor de internet.  Hay que preguntar velocidad de bajada y de subida.  Lo mejor es que sean simetricas.  Y sube a muy alta velocidad

Si de bajada tenes 50 megas capaz que de subida tengas 6 megas. Segun el proveedor.

Si se satura la velocidad de subida.  Baja mucho la velocidad de bajada

Si se conectan desde fox a un servidor central por internet.  La velocidad que se usa en la central es la de subida.  Por eso se pone tan lento

Para referencia de velocidad.  Recuerden que la placa de red local tradicional usada es de 100 megas.

____________________________

*sqldata y sqldata2. tienen en cuenta todas estas cosas. de forma transparente

*sqldata y sqldata2. esta basada en cursoradapter. 

*sqldata y sqldata2. crecen a medida que me van reportando errores y mejoras. de todos los usuarios. y otras que hago. tambien, cambios debido a nuevos controladores odbc, oledb. y las mejoras son para todos los colegas.

*un unico metodo de programacion para todas las bases de datos.

*programacion en cursores nativos vfp, luego la clase convierte las modificaciones a instrucciones de sql, y lo envia al servidor.

*sqldata nacio para sql server 2000 unicamente, en el año 2004. desde entonces la actualizo continuamente

*sqldata y sqldata2 , las ultimas versiones siempre son compatibles con las anteriores.  solo deben cambiar sqldata.vcx,vct o sqldata2.vcx,vct

comparto mi carpeta de utilidades

https://mega.nz/folder/xZ1SVZSa#1j9l5HW3u_JSiHCzaaHNtg

pueden ver los archivos de textos, para detalles   

[Enrique]

Muchas Gracias  gfva, por tu respuesta. Parece que es mas difícil de lo que pensaba. Visitare tu carpeta de utilidades. 

Muchas gracias nuevamente. Espero no naufragar en el intento.