Un usuario preguntó 👇
¿Es cierto que es mejor utilizar el diseñador de datos para implementar un cambio a la vez porque está relacionado con el orden del script SQL? ¿Y que el diseñador carece de algunas capacidades SQL estándar que dificultan la navegación?
Siempre lucho un poco con el diseñador, siempre encuentro errores, y no todos son tan fáciles de resolver, incluso al resolver el problema de SQL. Parece ser más fácil crear una tabla de lo que desea desde el principio, pero ahora, mientras escribo eso en voz alta, recuerdo que era una de las características de SQL 😀
https://pasteboard.co/J0rvnrl.png
Cuando intento agregar AUTO_INCREMENT por primera vez, aparece el error: Definición incorrecta de la tabla; solo puede haber una columna automática y debe definirse como una clave
y cuando trato de convertirlo en una escuela primaria? clave, aparece el error: Duplicar la entrada ‘0’ para la clave ‘PRIMARIA’
¿Qué estoy haciendo mal?
Lo siento si estoy buscando algo obvio aquí jaja.
(@peterschulznl)
hace 11 meses
Hola John,
Si tiene una columna de incremento automático en una tabla, esa columna debe ser la única columna clave. Eso tiene sentido, ya que su columna de incremento automático reconoce de forma única cada fila y no requiere una columna adicional.
Probablemente la razón por la que recibe este error es porque su tabla ya tiene una clave principal y su declaración de intercambio de tabla intenta agregar otra. ¿Está bien? Primero debe dejar el índice y luego la tabla posterior, o eliminar la tabla y luego volver a crearla.
Déjeme saber si esto ayuda…
Todo lo mejor, Peter
PD: ¡El diseñador de datos necesita más atención! En este punto, creo que, si es posible, la mejor manera de usar el Diseñador de datos es desplegar la tabla y volver a crearla …
(@peterschulznl)
hace 11 meses
Hola John,
¿Se resuelve este tema?
Gracias Peter
Lanzador de hilos
(@cityjohn)
hace 11 meses
Hola Peter,
Gracias por volver a mí más rápido que nadie antes, lo siento, no pude devolver el favor jaja. Después de soltar el índice, todavía recibo este error:
The following ALTER TABLE statement failed
ALTER TABLE <code>startracker_tutors</code> MODIFY COLUMN <code>ID</code> int(10) NOT NULL AUTO_INCREMENT;
ALTER TABLE <code>startracker_tutors</code> ADD PRIMARY KEY (<code>ID</code>);
Incorrect table definition; there can be only one auto column and it must be defined as a keyY quieres convertirlo en una clave principal.
Si primero elimino «auto_increment» para convertir la columna de ID en una clave, devolverá el siguiente error:
The following ALTER TABLE statement failed
ALTER TABLE <code>startracker_tutors</code> MODIFY COLUMN <code>ID</code> int(10) NOT NULL;
ALTER TABLE <code>startracker_tutors</code> ADD PRIMARY KEY (<code>ID</code>);
Duplicate entry '0' for key 'PRIMARY'Actualmente no hay ninguna columna configurada como ‘Clave’ y no puedo configurar una, por lo que sigo su consejo y reconstruyo toda la tabla.
Dado que estoy construyendo una base de datos de seguimiento de tutores y estudiantes, me estoy tomando mi tiempo para diseñarla correctamente y adelantarme a cualquier necesidad futura que pueda surgir, tengo Microsoft Access instalado para crear un esquema primero y luego recrearlo en wpda. No creo que el cliente mysql se pueda usar junto con el editor wpda.
También estoy viendo si puedo fusionar la tabla wp-user con mi tabla de usuarios y permitir que los usuarios administren sus propios datos de contacto. Esto eliminaría la necesidad de agregar un administrador de usuarios. Pero no estoy del todo seguro de que sea una buena idea.
Muchas gracias por el hombre del enchufe, ¡aprendió toneladas!
Lanzador de hilos
(@cityjohn)
hace 11 meses
Sabes, noté algo extraño. No sabía que cada tabla solo podía tener una clave principal, así que creé la tabla de estudiantes con muchos PK … Ahora que sé que no debería ser, creo que es extraño.
Leer mi base de datos en un banco de trabajo MySQL dice:
Table: startracker_pupils
Columns:
ID int(11) AI PK
date_created datetime
date_modified datetime
name varchar(64) PK
rate varchar(10)
wpID int(11)¿Debería ser posible?
(@peterschulznl)
hace 11 meses
Hola John,
¡Puedes fusionar la tabla wp_users! Si planea construir un proyecto de datos, puede incluso crear una vista de la tabla wp_users para permitir que un usuario administrativo seleccione el usuario de WP de un cuadro de lista.
También puede usar la identificación de usuario de WP en la cláusula de su lugar (para mostrar datos solo de usuario) y usarla para restringir el acceso (página de perfil de estudiante, por ejemplo). Vea el primer enlace debajo de la variable de entorno $ $ USERID $$.
Puede encontrar más información sobre estos temas aquí:
https://wpdataaccess.com/docs/documentation/data-projects/managing-roles-and-user-access/
https://wpdataaccess.com/docs/documentation/data-projects/video-tutorials/#fine-tuning
Por cierto, ¡esto es lo más complicado! 🙂
Para crear su secuencia de comandos de tabla, una clave principal puede contener más de una columna. Entonces esto funcionaría:
primary key (IDENTIFICACIÓN,nombre)
Sin embargo, si su columna de ID es una columna de incremento automático, la columna de nombre no hace que la clave de prikary sea «más única». La identificación ya es única. Entonces sí, esto es posible, pero no tiene sentido si su columna de ID es un incremento automático.
¡Espero que esto ayude!
Todo lo mejor, Peter
(@dnuttall)
hace 11 meses
Peter / John: Para la clave principal (ID, nombre) y la suposición de que desea que un «nombre» sea único, ¿por qué no declarar INDEX UNIQUE un nombre?
¡Solo mis $ 0.02! (USD) Dave
Lanzador de hilos
(@cityjohn)
Hace 10 meses, 3 semanas
@peterschulznl Oke, descubrí cómo resolverlo todo usando PhPmyAdmin, parece un poco más fácil averiguar qué suerte estoy haciendo al diseñar esquemas de lectura. Lee un poco sobre claves también compuestas. Creo que lo entiendo ahora, aunque no sé exactamente cómo implementarlos.
El $$ USERID $$ parece bastante fácil de usar, todavía no lo he probado, pero la cláusula es fácil de entender.
La vista también es una característica muy agradable, pero según tengo entendido, esta vista no se traduce al esquema, ¿verdad? Da la casualidad de que la relación se almacena en WPDA y no en mi esquema, por lo que no pude ver o editar la vista u otras relaciones en PHPmyadmin.
Lo que realmente quiero es que la administración no tenga que asignar una ID de WP a cada instructor, estudiante y padre. Entiendo que el esfuerzo que me cuesta aprender y aplicar es radicalmente desproporcionado a cualquier ganancia que alguien pueda obtener con 2 tutores y 3 estudiantes en total, pero desde el cierre de la universidad todos he estado en este maravilloso panel para crear.
@dnuttall Oye, gracias por la sugerencia, no quiero tener un nombre único, pero me equivoqué al pensar que tenía que ser indexado para consultarme en función del nombre jaja.
¡Gracias por la ayuda!
(@peterschulznl)
Hace 10 meses, 3 semanas
Hola John,
Asegúrese de estar utilizando la versión 3.0.3 del plugin. Una nueva característica agregada a la versión 3.0.3 fue un vistazo a otros esquemas… 🙂 ¡Buena suerte! 😉
Todo lo mejor, Peter
¿Solucionó tu problema??
0 / 0