Citar:

Siempre tendremos una gran similitud. Bueno, esto me lo he ido currando viendo los vídeos en ingles..
( Parece una forma más corta a simple vista, tengo que verlo mejor. Naturalmente los ejemplos son distintos)

Bueno...no es lo mismo, ni la longitud del código debería ser importante. Ese código de python utiliza sólo llamadas a sentencias SQL. Com gambas también se puede hacer así.
La gracia de gambas está en la independencia del motor de la base de datos que te ofrecen los objetos de datos de Gambas.
Con un buen código gambas, puedes hacer programas que funcionen igual en mysql que en SQLite que en PostGre...

Saludos.

===================
No podemos regresar

Jorge:

Me supongo que habrá otras formas en Python como ocurre en Gambas.
Como siempre ocurre en programación, seguro que no es la única manera.

Citar:

Con un buen código gambas, puedes hacer programas que funcionen igual en mysql que en SQLite que en PostGre...

¿ Este código podría valer para distintos motores o se debe cambiar muchas cosas ?.

Sqlite3 con Gambas3

Observa el comentario final del documento.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Citar:

¿ Este código podría valer para distintos motores o se debe cambiar muchas cosas ?.

Teóricamente, está bien hecho,  lo único que hay que cambiar es aquello de miconexion.type="sqlite" por miconexion.type="mysql"

Citar:

Observa el comentario final del documento.

El comentario lleva razón cuando dice:

Citar:

se podría haber logrado el mismo resultado, pero con una programación más estándar ejecutando instrucciones SQL del tipo Insert, Update y Delete.

El estándar de la bases de datos es SQL, ergo, si usas SQL, tu código se acerca al estándar. Ahora bien, resulta que las bases de datos mismas no siguen exactamente el estándar. Un ejemplo lo tienes en el entrecomillado, cada base utiliza el suyo... que se parece a las demás y que muchas veces es igual... y otras no (de ahí que siempre aconsejemos aquello de los parámetros reemplazables en sentencias exec y demás &1, &2, etc). Sqlite, en concreto no es demasiado estándar, su propia naturaleza le dota de particularidades que están muy bien... pero que no son estándar. Lo mismo podemos decir de MySQL cuyas sintaxis no siempre siguen el famos estándar... etc.

Por tanto gambas ofrece una capa intermedia que nos "aleja" de esas peculiaridades y nos evita tener que adecuar el código a cada motor. No siempre lo consigue, hay de reconocerlo, pero para las operaciones normales sí. Crear y eliminar tablas, buscar, añadir, borrar y modiricar registros, etc. Es mucho más flexible -en el contexto que estamos hablando- que usar un SQL que luego puede no "casar" con la base de datos que usamos.

¿Qué pagamos a cambio? La velocidad. El manejo de datos "masivos" con objetos de gambas es significativamente más lento que con sentencias SQL. En esos casos hay que pensárselo mucho para decidir qué merece la pena hacer con objetos de gambas y qué no. Sin embargo para operaciones sobre un sólo registro, no lo dudéis: Gambas.

Saludos.

===================
No podemos regresar

La verdad es que ya se podían poner de acuerdo en el estándar de SQL. Quizás es una mejora adaptada a cada motor.

Citar:

¿Qué pagamos a cambio? La velocidad. El manejo de datos "masivos" con objetos de gambas es significativamente más lento que con sentencias SQL. En esos casos hay que pensárselo mucho para decidir qué merece la pena hacer con objetos de gambas y qué no. Sin embargo para operaciones sobre un sólo registro, no lo dudéis: Gambas.

No vamos a trabajar solo con un registro.  Cuando hacemos consultas trabajamos con muchos registros.
Como tu dices es una capa, una traducción que lleva su tiempo de interpretación.

El problema que podemos encontrarnos los que tenemos menos experiencia es que lleguemos a mezclar las dos maneras, objetos y sql..
Luego vienen los malos hábitos. Y estemos más perdió que un peo en un Jacuzzi.

Acostumbrarte solo a las comodidades que te da un lenguaje, tampoco es adecuado. Aprender un estándar, si.
Ya que puede valerte en otros lenguajes de programación.  Tu eso lo sabes mejor que yo. No es lo mismo llevar
una base de datos de un pequeño negocio, que algo donde pueden haber miles y miles de registros. Una administración regional.

Eso no quiere decir que en la base del pequeño negocio luego no haya tambien mil registros.
Hospedería, ferretería...

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Citar:

Ya que puede valerte en otros lenguajes de programación.  Tu eso lo sabes mejor que yo.

Aquí hay más cosas en juego, además de tu "curva de aprendizaje", a la hora de decidir qué vas a usar en tu código.

- La portabilidad de tu código: Si lo que haces es un "algo" (formulario, componente, control, clase, etc) que tiene que ser reutilizado en otras aplicaciones: Por ejemplo: el formulario "Login" que consulta una base de datos de usuario, el formulario que envía correos, etc. La mejor solución: Objetos de Gambas.

- La perspectiva de modificación de tu entorno: Si lo que haces tiene alguna posiblidad de cambio de base de datos o de sistema operativo... Así si haces un programa para un pequeño negocio... nadie te asegura que el negocio no crezca y, por ejemplo, abra una sucursal, en tal caso SQLite no vale y hay que usar algo más serio: También gambas es la solución

- En los procesos masivos como copias de seguridad, cambios de versión con actualización de la base de datos, etc, etc.: SQL

- La necesidad de velocidad en momentos muy concretos de la programación. En las operaciones "Normales" que más arriba mencionaba, es insignificante pero , por ejemplo: Yo, después de cada actualización u operación que hago de los datos (consultas, listados, modificaciones,  etc.) grabo en una tabla de log el nombre del usuario la fecha y la hora y un resumen de lo que ha hecho. Esta operación de log no puede ser lenta, por lo que utilizo una sentencia insert.

- La coherencia, el "estilo", de tu programación. Si en unos programas haces las cosas de una manera y en otros de otra, puede ser interesante para aprender pero puede ser una tortura al modificar el código x meses/años después. Un estilo coherente (ojo, no inmóvil, sino coherente) ayuda mucho en eso. (Ante un fallo ya puedes descartar, de entrada, todo aquello que "yo nunca haría".

Todo eso hay que valorarlo antes de escribir ni una sola línea de código, que mira que nos encanta eso de lanzarnos a teclear... para arrepentirnos después.

Saludos.

===================
No podemos regresar

Añadir registros es tan fácil como:
Después de haber creado las tablas tal como pone SHELL en su ejemplo:
      
      Try $Conn.EXEC("insert into Sexo values (&1, &2)", "H", "Hombre")
      Try $Conn.EXEC("insert into Sexo values (&1, &2)", "M", "Mujer")
      
      Try $Conn.EXEC("insert into Estado_Civil values (&1, &2)", "S", "Soltero/a")
      Try $Conn.EXEC("insert into Estado_Civil values (&1, &2)", "C", "Casado/a")
      Try $Conn.EXEC("insert into Estado_Civil values (&1, &2)", "P", "Pareja Conv.")
      Try $Conn.EXEC("insert into Estado_Civil values (&1, &2)", "X", "Separado/a")
      Try $Conn.EXEC("insert into Estado_Civil values (&1, &2)", "D", "Divorciado/a")
      Try $Conn.EXEC("insert into Estado_Civil values (&1, &2)", "V", "Viudo/a")

Tabla Sexo: columnas id y sexo
Tabla Estado_Civil: columnas id y estado.

¿Por qué los try?

===================
No podemos regresar

Shordi:

Tengo que apuntar bien las ultimas aclaraciones de si usar objetos de gambas o directamente el lenguaje SLQ. Son muy interesantes.

Citar:

- La perspectiva de modificación de tu entorno: Si lo que haces tiene alguna posiblidad de cambio de base de datos o de sistema operativo... Así si haces un programa para un pequeño negocio... nadie te asegura que el negocio no crezca y, por ejemplo, abra una sucursal, en tal caso SQLite no vale y hay que usar algo más serio: También gambas es la solución

Me supongo que te habrás visto en eso más de una vez. Sería interesante probar otro motor para ver como va eso de más de un usuario con la misma
base de datos. Distintos ordenadores,etc. También podría ser el mismo ordenador y distintos usuarios.

Supongamos este caso en Sqlite. Tengo un tabla de clientes de una empresa con unos campos creados y tiene a lo mejor 100 registros en esta tabla.
Ahora el cliente quiere que añadas un campo más a esa tabla. Por ejemplo teléfono. (por decir algo).  ¿ Es fácil  de cambiar la tabla en si ?.
Supongo que siempre sera mejor crear una tabla nueva y ale, uno por uno ir añadiendo registros a la tabla nueva y añadir datos al campo nuevo creado.

Me supongo que habrá profesiones que consisten en eso. Todo el día tecleando datos en bases de datos.

Citar:

- La coherencia, el "estilo", de tu programación. Si en unos programas haces las cosas de una manera y en otros de otra, puede ser interesante para aprender pero puede ser una tortura al modificar el código x meses/años después. Un estilo coherente (ojo, no inmóvil, sino coherente) ayuda mucho en eso. (Ante un fallo ya puedes descartar, de entrada, todo aquello que "yo nunca haría".

Es distinta la perspectiva cuando se esta aprendiendo a cuando quieres hacer algo determinado y tener unos hábitos o costumbres bien adquiridos.
Pero para eso antes hay que practicar y ver que puede ser mejor. Eso puede llevar un tiempo.  Lo suyo es leerse un buen libro de SQL y preguntar en la comunidad.

Citar:

Todo eso hay que valorarlo antes de escribir ni una sola línea de código, que mira que nos encanta eso de lanzarnos a teclear... para arrepentirnos después.

Con la practica todo se hace más rutinario. La creación de las tablas hay que estudiarlas, es normal.

frajanic:

Efectivamente era sencillo insertar registros con la instrucción exec.

¿ Siempre usas Try ?. Tu sabes que la tabla esta creada y que existe.
En caso de que faltase algún dato a ingresar desde el formulario se puede comprobar que esos componentes de entrada, tengan datos y no estén vacíos.
Quizás con eso no necesites Try.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Citar:

Tengo un tabla de clientes de una empresa con unos campos creados y tiene a lo mejor 100 registros en esta tabla.
Ahora el cliente quiere que añadas un campo más a esa tabla. Por ejemplo teléfono. (por decir algo).  ¿ Es fácil  de cambiar la tabla en si ?.
Supongo que siempre sera mejor crear una tabla nueva y ale,

La mecánica para añadir un campo es muy simple: Un comando sql y ya está.
Internamente el motor de SQLite lo que hace en estos casos es una copia de la tabla con un nombre temporal, crear la tabla nueva, rellenarla con los datos de la tabla temporal y eliminación de la tabla temporal.

Con SQLite no, que no llega a tanto, pero con otras bases eso de crear una tabla nueva tiene su miga, porque la propia BD se encarga totalmente de las referencias entre tablas y la integridad referencial, es decir, todas las demás tablas que apunten a la tabla vieja, a la que renombraste... siguen apuntando a la tabla vieja, la renombrada, con lo que te tocaría ir cambiando la relación en todas las demás. Mucho más fácil modificar la tabla , ya digo, una instrucción y ya está.

Saludos.

===================
No podemos regresar

Citar:

Quizás con eso no necesites Try.

Try no debería usarse nunca sin un "if Error" después. El propósito de try es evitar el aborto del programa en caso de error pero las consecuencias de ese error se mantienen, por supuesto. Por eso hay que controlarlo.

Sólo hay alguna ocasión en la que try viene bien... y sólo para evitar escribir código, no por otra cosa. Por ejemplo:
Tienes que editar un fichero en la carpeta /tmp. Si no existe primero tienes que copiarlo. Lo normal sería:



Ahorras alguna línea con


Si ya existe se levantará un error, pero no se detendrá el programa.

Por supuesto que este ejemplo es una chorrada, pero valga como ilustración. Fuera de este uso Try, así sin más, no debería utilizarse nunca. En el ejemplo que nos ocupa de frajanic, si la tabla está bloqueada, por ejemplo, por otro usuario o hay cualquier problema, no nos enteraremos y el registro quedará sin grabar.

===================
No podemos regresar