Buenos días!.

¿ Cual es el estado del gestor de base de datos de gambas ?.
Estuve recordando cosas con este gestor y ahora que lo vuelvo a ver, ha cambiado en muchos sentidos.

Tiene cosas nuevas, pero otras parecen incompletas, otras se han eliminado.  

A ver:

- La opción de copiar y pegar tabla, ¿  funciona ?.
- ¿ Que es "cotejamiento ?. Aparecen valores en la lista tales como: Binary, Nocase, Rtrim
- ¿ Por qué se ha eliminado la opción crear código de la creación de las tablas ?. ( Utilidades del gestor).

Aunque uso la opción de copiar Tabla, no puedo pegarlo luego en un archivo de texto.
Y aunque diga copiar la lista de campos , tampoco hace nada.

¿ Se encuentra algo abandonado el proyecto del gestor ?.
A lo mejor no lo hago de la forma adecuada.

Saludos

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

Esto es lo que sale al copiar tabla. Parece como si fuera a copiarla en el árbol de tablas.
Aunque da la posibilidad de otros directorios.

 

Lo que hace como mucho renombrar la tabla y copiar el contenido de los registros.

Saludos

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

Alguien sabe de las propiedades de conexión, ¿ qué es...?

 

- Mostrar metadatos

- Recordar la estructura de la base de datos.

¿ No la guardarnos siempre cuando escribimos las tablas ?.

- Ignorar codificación de los caracteres de la base de datos.

¿ Eso no dará algún problema ?.

Saludos

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

Al abrir con Sqliteman puedo ver cosas que el gestor de gambas no me muestra:

Esto es cuando se activa metadatos.

 

Saludos

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

Buff. Muchas preguntas. Te contesto la que tiene que ver con las bases de datos en sí, no las del gestor de gambas porque yo no lo uso. Es muy limitado.

Citar:

¿ Que es "cotejamiento ?. Aparecen valores en la lista tales como: Binary, Nocase, Rtrim

El cotejamiento, collation en inglés, es el conjunto de normas que se siguen a la hora de hacer manejos con los datos. Cosas como ordenar, comparar, etc. necesitan una serie de reglas (¿qué va antes mayúsculas o minúsculas, las letras con tilde o sin ella, etc. etc.?) que dependen del idioma que se use en la base de datos, más concretamente de las páginas de códigos que utiliza éste idioma. Si tu base de datos utiliza una página de códigos inglesa, por ejemplo, no sabrá qué hacer con las vocales acentuadas y demás.

MySQL (¡y gambas!) se decantan por el uso de utf-8 al establecer el collation, pero es cosa de cada país. Puedes tener problemas con ello si te cierras a un país concreto y luego recibes actualizaciones y consultas desde clientes que usen otro idioma.

En SQLite nunca me lo he planteado demasiado, hasta donde sé lo sacan del idioma del sistema.

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

No tenía ni idea del problema del código de página en las bases de datos.

Citar:

MySQL (¡y gambas!) se decantan por el uso de utf-8 al establecer el collation, pero es cosa de cada país. Puedes tener problemas con ello si te cierras a un país concreto y luego recibes actualizaciones y consultas desde clientes que usen otro idioma.

En SQLite nunca me lo he planteado demasiado, hasta donde sé lo sacan del idioma del sistema.

¿ Te ha ocurrido ese problema ?. A ver que nos comentan los compañeros del otro lado del "charco".

Saludos

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

A este lado del charco igual que en el otro, usamos vocales acentuadas, por poner un ejemplo. Si seleccionas un cotejamiento inadecuado, tendrás problemas.

Aunque shordi tiene mucha más experiencia en bases de datos que yo, al menos en el terreno de aplicaciones de escritorio, yo he trabajado bastante con servidores web y mysql y mi consejo es la utilización de utf-8. La tendencia general es esa, por varios motivos muy largos de explicar aquí (básicamente la globalización y los caracteres multibyte de otros alfabetos).

Así que tú mismo...

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Lo decía, por poner un ejemplo. México, esta cerca de los USA, que no usan vocales acentuales.

Si una empresa de programación de México crea registros usando vocales acentuadas y tienen clientes en USA,
pues por decirlo de alguna forma, algún problema les dará.  

Saludos

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

Citar:

¿ Te ha ocurrido ese problema ?. A ver que nos comentan los compañeros del otro lado del "charco"

Sí que me ha ocurrido, me volvió loco, motivó cambios en el código del driver de gambas... y aún me ocurre de vez en cuando.

El tema es que los servidores MySQL tienen, tienen que tener, un time-out de conexión inactiva. ¿Cómo van a saber ellos que tú de repente has cerrado tu página web o has apagado el ordenador o lo que sea? Se quedarían sesiones abiertas hasta el infinito.
Cuando un usuario abre su programa de gambas y establece la conexión y entonces, como me ocurre con el programa de los abogados, se tira horas rellenando un documento de libreOffice, al volver al programa el servidor remoto ha cortado la conexión, pero el programa de gambas no lo sabe, lanza su nueva consulta con una conexión "zombie" y el servidor la acepta... pero con los parámetros por defecto, o sea, USA.
El efecto es que, de repente, un gridview, por ejemplo, aparece llenito de símbolos raros donde debiera haber acentos.

Le pasé el bug a Benoit, lo corrigió y ahora en un 99,99% de los casos no ocurre y todo funciona bien. Sin embargo no dejo de avisar a los usuarios "Si de repente ves que los acentos desaparecen, no grabes nada. Cierra el programa y vuelve a entrar." ¿Por qué lo de no grabar nada? porque el problema se multiplica: los acentos que han sido representados con caracteres raros se intentan grabar con la página de códigos buena, con lo cual se re-codifican en caracteres aún más raros que se vuelven a re-codificar en la siguiente grabación, etc. etc.

Ya digo que es un bug en el que ahora ni pienso, hace como 6 meses que no lo he visto, pero que todavía ocurre de vez en cuando.
Las soluciones van desde una función que busque los caracteres raros en todos los campos antes de grabar (la tuve que hacer, claro) hasta un timer en el formulario principal que cierre y abra la base cada X tiempo para soslayar el time-out...

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

Citar:

y mysql y mi consejo es la utilización de utf-8.

100% de acuerdo. Utf-8 es el defecto de MySQL y el de gambas. Más aún, yo me limito al utf8-general no al utf8-latino. El general no da ningún problema y es más estándar.

Saludos.

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