Crear una base de datos para gestionar cuotas de alumnos

jucasaca in LibreOffice-ES


Mario Mey
Che… estoy recibiendo muchos mensajes de error… y no sé bien si estoy haciendo algo muy mal o algo en el software anda muy mal. Por ejemplo, creo una tabla, la guardo. No agrego nada, la edito y le doy a un campo que sea de “Valor automático”. Me dice…

La modificación de los campos es muy difícil, especialmente difícil es la modificación de los campos autoincrementales y de las claves, tanto primarias como foráneas. Eso no es un error de Base, esos es un problema de la base de datos, que en este caso es Firebird, pero la mayoría de las bases de datos tienen este “problema”.
La manera de evitarlo es meditar bien el diseño antes de comenzar. Es lo que te decía, estas muy preocupado por hacer la macro pero no en diseñar las tablas.
Una posible solución, si ya tienes la tabla con datos es crear el diseño (esta vez bien creado, con el campo autonumérico) y luego:
— hacer clic derecho sobre la tabla que tiene los datos
— seleccionar copiar
— hacer clic sobre la nueva tabla vacía
— seleccionar pegar
— selecciona anexar datos y siguiente
— aparecen dos listas con los campos de la tabla vieja a la izquierda y los de la nueva a la derecha. En esta lista quita la selección (para no copiar) del campo que no era autonumérico en la tabla vieja. El resto de los campos deberán estar enfrentados el origen con el destino.
— haz clic en crear.
Como la tabla nueva no se puede llamar como la vieja, habrás tenido que dar un nombre que no luego no se puede cambiar, truco:
— elimina la tabla vieja
— selecciona la tabla nueva y selecciona copiar en el menú contextual
— En el siguiente paso pon el nombre que desees a la tabla que se va a crear uy selecciona también Definición y datos
— pasa todas las columnas a la derecha en este nuevo paso.Ten cuidado de pasarlas en el orden que las quieras, que el orden tampoco se puede cambiar
— en el siguiente paso de formatos y tipos, no modifiques nada y haces clic en crear

En realidad, se podría haber modificado todo con un par de ordenes SQL, pero además de que también se pueden generar problemas (y quizá más gordos) estas órdenes no son fáciles, pero si sientes la necesidad, en el manual de Firebird las puedes encontrar (en ALTER TABLE, más concretamente)

t.me/libreoffice_es/92000

Jun 15 at 22:28

jucasaca in LibreOffice-ES


Mario Mey
Photo

Esto sí que me resulta raro.
¿Por qué no vas compartiendo la base de datos como la tengas cuando te pasa algo. Nos facilitaría mucho poder ayudarte. Como consejo, olvídate de momento de los datos verdaderos y trabaja con datos ficticios y tablas con pocos datos, pero que te permitan entender lo que haces y lo que pasa.

t.me/libreoffice_es/92001

Jun 15 at 22:38

jucasaca in LibreOffice-ES

Y por cierto, ahora que estas empezando ¿seguro que un entero es el formato numérico adecuado para la cuota? Los enteros no admiten decimales ¿seguro que nunca los necesitarás? Para mi sería más adecuado un formato NUMERIC o DECIMAL con un par de decimales

t.me/libreoffice_es/92002

Jun 15 at 22:42

Emi Gonzalez Salgado in LibreOffice-ES

Cuando se diseña una BBDD no hay que tener prisas en formularios, macros, etc.
Primero papel y lápiz. Pensar que se quiere hacer.
Necesitas, alumnos y socios. Diseña bien esas tablas, y piensas si necesitas alguna tabla auxiliar para datos que se usan en muchos de los registros. Y Luego las relacionas.
Los recibos, igual. Son por alumno, tendrás que poner si están pendientes o pagados. A quien se le cobran y cómo: metálico, banco, etc.
Los errores en el diseño son los más difíciles de solucionar. Ya te ha pasado.
Si no corres tanto avanzaras más rápido.
Hazle caso a Juan Carlos, por un ejemplo.
Saludos,

t.me/libreoffice_es/92003

Jun 15 at 23:11

Mario Mey in LibreOffice-ES

Bueno, el tema del macro, tengo para decir: no encontré la forma de lograr lo mismo que me daba el macro… así que volví a activarlo y lo puse en los dos formularios: ALUMNES y SOCIES. Pueden verlo funcionando ahí mismo.

Entiendo que no es aconsejable andar cambiando campos de una tabla ya hecha… aunque me parece que debería esperarse que alguien (como yo) quiera hacerlo y que sea claro el mensaje de que no es posible hacerlo. Al menos yo no me manejo bien con códigos de error, no me son muy descifrables.

Eso sí, si tengo que cambiar campos de una tabla… si no me queda otra, seguiré tus consejos o empezaré todo de nuevo :person_shrugging:.

Repito que nunca trabajé con Base, ni tampoco hice algo parecido en otro software… ni tampoco necesité hacer algo como lo que necesito ahora. Por eso, a medida que aprendo, intento hacer andar, me topo con mil errores, voy cambiando el diseño de la tabla por mi conveniencia, etc, etc.

t.me/libreoffice_es/92006

edited Jun 16 at 01:06
Alumnes para compartir.002.odb (103,8 KB)

Mario Mey in LibreOffice-ES

Bueno, el tema del macro, tengo para decir: no encontré la forma de lograr lo mismo que me daba el macro… así que volví a activarlo y lo puse en los dos formularios: ALUMNES y SOCIES. Pueden verlo funcionando ahí mismo.

Entiendo que no es aconsejable andar cambiando campos de una tabla ya hecha… aunque me parece que debería esperarse que alguien (como yo) quiera hacerlo y que sea claro el mensaje de que no es posible hacerlo. Al menos yo no me manejo bien con códigos de error, no me son muy descifrables.

Eso sí, si tengo que cambiar campos de una tabla… si no me queda otra, seguiré tus consejos o empezaré todo de nuevo :person_shrugging:.

Repito que nunca trabajé con Base, ni tampoco hice algo parecido en otro software… ni tampoco necesité hacer algo como lo que necesito ahora. Por eso, a medida que aprendo, intento hacer andar, me topo con mil errores, voy cambiando el diseño de la tabla por mi conveniencia, etc, etc.

t.me/libreoffice_es/92006

jucasaca in LibreOffice-ES


Mario Mey
Bueno, el tema del macro, tengo para decir: no encontré la forma de lograr lo mismo que me daba el macro… así que volví a activarlo y lo puse en los dos formularios: ALUMNES y SOCIES. Pueden verlo funcionando ahí mismo. Entiendo que no es aconsejable andar…

Que no está mal que haya macros para buscar, pero es mejor olvidarlas hasta que tengas un diseño de tablas consistente. Es mejor no perder el tiempo en enlazar la macro en cada formulario si el formulario aún no es definitivo porque la tabla no lo es. Por cierto, deberían ser LAS macros, en femenino, porque el origen de la palabra es la abreviación de “las macroinstrucciones”

t.me/libreoffice_es/92008

Jun 16 at 15:38

jucasaca in LibreOffice-ES


Mario Mey
Entiendo que no es aconsejable andar cambiando campos de una tabla ya hecha… aunque me parece que debería esperarse que alguien (como yo) quiera hacerlo y que sea claro el mensaje de que no es posible hacerlo. Al menos yo no me manejo bien con códigos de error, no me son muy descifrables.

No importa cambiar mil veces los campos mientras estás en la fase de diseño, hasta que des con el tipo de datos y el nombre adecuados. Lo que no se puede es cambiar un diseño, porque no lo has probado suficiente, cuando la base de datos está en producción.
Se supone que la base de datos estará en producción muchos años, así que no es problema gastar unos días en diseñar bien y luego olvidarte de por vida (aunque eso es muy complicado)

Cometer errores y corregirlos es una buena forma de aprender. Cometer errores e ignorarlos es la forma de fracasar seguro.

t.me/libreoffice_es/92009

Jun 16 at 15:40

Mario Mey in LibreOffice-ES

Un campo de id, ¿qué tipo debe ser? ¿INTEGER?

t.me/libreoffice_es/92010

Jun 16 at 15:41

jucasaca in LibreOffice-ES
Puede ser de cualquier tipo, pero para la mayoría de la gente lo más cómodo es un entero automático.
https://t.me/libreoffice_es/92011

jucasaca in LibreOffice-ES

Algunas recomendaciones:
— Hay varios campos cuyos datos se repiten en los registros, como por ejemplo, en CUOTAS “forma”, que yo entiendo que es la forma de pago y tendría algo así como “contado”, “tarjeta”, “bizum”.
Pues bien, este tipo de datos, así, en varchar escritos, pueden generar problemas. Por ejemplo si alguien escribe “bizun” o “Bizum” no aparecerán en las consultas en las que pidas “pagado con bizum” (WHERE “forma” = ‘bizum’)
La manera de solucionar esto es con una tabla auxiliar de formas de pago que estará relacionada con la tabla CUOTAS en las que el campo “forma” sea entero con una lista para seleccionar los tipos (no sé si me he explicado)
— Los tamaños de los campos se pueden modificar para ampliar el tamaño, pero nunca se puede reducir el tamaño. Si el campo “curso” va a tener una o dos cifras, es absurdo que tenga un tamaño de 255. Sería mejor poner un tamaño de 2 o 3 y si luego fuera necesario ampliarlo. Aunque en principio, en un varchar parece que no importa, a veces al crear formularios aparecen controles tan grandes que no puedes manejar, o al exportar, columnas de un ancho innecesario

t.me/libreoffice_es/92012

Mario Mey in LibreOffice-ES

Lo de la forma de pago sí, lo había pensado así para el campo “caracter_socio” o “anual_mensual”. Ahora que lo decís, voy a tenerlo en cuenta para algún campo que también lo convenga.

Después se le puede hacer un botón de opción para elegir, ¿no?

t.me/libreoffice_es/92013

jucasaca in LibreOffice-ES

Mario Mey
Lo de la forma de pago sí, lo había pensado así para el campo “caracter_socio” o “anual_mensual”. Ahora que lo decís, voy a tenerlo en cuenta para algún campo que también lo convenga. Después se le puede hacer un botón de opción para elegir, ¿no?

https://t.me/libreoffice_es/92015

Mario Mey in LibreOffice-ES
¿Probaste este archivo? ¿Te saltan los mismos errores que a mí?
https://t.me/libreoffice_es/92014

jucasaca in LibreOffice-ES


Mario Mey
¿Probaste este archivo? ¿Te saltan los mismos errores que a mí?

Sí, y no lo entiendo. Creo que lo que hiciste fue convertir la base HSQL a Firebird y eso es lo que está produciendo el error

t.me/libreoffice_es/92016

jucasaca in LibreOffice-ES

Te mando otra DB hecha desde el principio en Firebird, en la que ha puesto algunos ejemplos de formularios para que veas que se puede ir haciendo casi todo (¡Ya añadirás el buscar! :stuck_out_tongue_winking_eye:)
Y en esta sí que funciona tu consulta, la que daba error

socios.odb (48,0 KB)

t.me/libreoffice_es/92018

jucasaca in LibreOffice-ES

Nujeva BD en Firebird con ejemplo de formularios

t.me/libreoffice_es/92019
socios.odb (47,3 KB)

jucasaca in LibreOffice-ES

¡Ah!, otro par de consejos que se me olvidaban
— No es buena idea poner la edad, a medida que los años pasan, las edades cambian. Lo mejor es poner la fecha de nacimiento que la edad se puede calcular en cualquier momento.
— A las cuotas le faltaba una manera de ver si están pagadas o no. En principio, lo más intuitivo es poner un campo sí/no, pero yo te recomiendo poner uno de fecha de pago, así, además de ver si está pagado o no, puedes ver cuanto se ha ingresado entre dos fecha determinadas

t.me/libreoffice_es/92021

Mario Mey in LibreOffice-ES

Pregunta, yo tengo una planilla Calc con todos los alumnos y sus datos. Quiero copiar y pegar todo esto. Para hacerlo, pegaba directamente en Base y ahí mismo construía la tabla con estos datos. Teniendo una tabla ya hecha, ¿puedo pegar los datos ahí mismo? ¿O me conviene nuevamente crear una nueva tabla con todos los datos?

t.me/libreoffice_es/92023

jucasaca in LibreOffice-ES


Mario Mey
Pregunta, yo tengo una planilla Calc con todos los alumnos y sus datos. Quiero copiar y pegar todo esto. Para hacerlo, pegaba directamente en Base y ahí mismo construía la tabla con estos datos. Teniendo una tabla ya hecha, ¿puedo pegar los datos ahí mismo?…

Se pueden copiar los datos en la tabla existente. De hecho, yo creo que es mejor crear la estructura y luego pegar los datos.
Así, por ejemplo, ya tendrás creado el id automático y luego no te creará quebraderos de cabeza. Además, al crear la tabla de Base pegando desde Calc, los tipos de datos no se corresponden generalmente, con lo que se desea, aunque se pueden modificar en el camino, a veces te confunde…
Calc tiene muchos menos tipos de datos que las bases de datos.

t.me/libreoffice_es/92024