Esta página describe Calíope 1.5, la versión que estamos construyendo ahora mismo. La 1.4 está terminada y en revisión de App Store, y la tienda sirve hoy la 1.3 en el Mac y la 1.2 en iPad. El changelog dice en qué versión llegó cada función.
Añade un botón «Abrir en Calíope» a cada tema. Sólo funciona con la app instalada.
Qué le ha fallado a Calíope, cuándo y en qué dispositivo.
Dónde está: Espacio de Trabajo › Herramientas › Errores
El Registro de errores guarda una fila por cada fallo de la aplicación, con su fecha en hora universal, el dispositivo donde ocurrió, el área afectada y el perfil de conexión implicado, si lo había.
No es el registro de consultas. Aquél guarda lo que el servidor contesta a una sentencia —un ERROR 1064 de sintaxis, por ejemplo—, que es el resultado normal de escribir SQL. Éste guarda lo que le pasa a la app: una conexión que no se establece, un túnel que se cae, un respaldo que no se puede escribir.
Funciona sin conexión, y está así a propósito: el registro es local y hay que poder leerlo justo cuando no se puede conectar, que es cuando más falta hace.
Qué no se guarda nunca: ninguna contraseña, ni siquiera truncada. Un fallo de autenticación registra que falló y contra qué perfil, nunca con qué credencial. El servidor se identifica por el alias del perfil, no por host, puerto y usuario.
Un fallo que se repite solo no llena el registro. El monitor de salud sondea cada servidor cada pocos segundos, así que uno apagado dejaría miles de filas idénticas en una noche. Se anota la primera vez, y se vuelve a anotar si el problema cambia, si el servidor se recupera y vuelve a fallar, o si sigue igual seis horas después. Ver una sola fila no significa que ocurriera una sola vez.
Doble clic en una fila (o un toque en iPad) abre el detalle completo, con el texto técnico que sirve para soporte y un botón para copiarlo. Si el error tiene explicación propia, ahí está el botón Ver solución.
Cómo funciona la sincronización del registro y qué sale del dispositivo.
Dónde está: Calíope › Preferencias › General
El registro se puede espejar en tu iCloud privado, de modo que lo que falló en el iPad se vea también en el Mac. Cada fila conserva el dispositivo donde ocurrió: un registro fusionado en el que no se sabe quién escribió cada línea no sirve para diagnosticar.
El interruptor empieza apagado, y no es un descuido. Un registro local es un archivo tuyo en tu equipo; subirlo saca de tu dispositivo los alias de tus perfiles y el detalle técnico de cada fallo. Eso se pide, no se presupone. Está en Preferencias › General, separado del interruptor que activa el registro: uno decide si se guarda, el otro si sale de aquí.
Por qué no va con el resto de preferencias. Las preferencias viajan por un almacén pequeño de iCloud con un tope de un megabyte compartido por todo; cuando se agota, deja de sincronizarse todo, no solo lo que lo llenó. Un registro de errores crece con el uso, así que va por otro canal —CloudKit, registro a registro—, que además permite que el Mac, el iPad y el iPhone escriban a la vez sin pisarse.
Retención. Se conservan 90 días por omisión, ajustable en Preferencias. La poda se aplica en el archivo local y en iCloud, así que vaciar el registro no deja una copia arriba que vuelva a bajar en la siguiente sincronización.
El servidor no respondió: qué comprobar y en qué orden.
Aplica a:MySQLMariaDBAurora
Este error significa que el intento de conexión no llegó a hablar con ningún servidor: o no hay nada escuchando en ese host y ese puerto, o algo por el camino lo impide.
En orden, de lo más probable a lo menos:
1. El host y el puerto del perfil. El puerto por omisión es 3306; un servidor en contenedor suele publicar otro.
2. El servidor está encendido. Compruébalo desde la misma máquina donde corre, si tienes acceso.
3. El túnel SSH, si lo usas. Un fallo de túnel se presenta muchas veces como «no conecta»: mira antes si hay un error de SSH en el registro, justo por delante de éste.
4. El cortafuegos o la red. Una VPN caída, una red corporativa que filtra el 3306 o una regla de grupo de seguridad en la nube dan este mismo error.
5. A qué interfaz escucha el servidor. Un servidor que solo escucha en 127.0.0.1 es inalcanzable desde otra máquina aunque esté encendido; ahí la solución es un túnel SSH, no abrir el puerto.
La conexión llegó, pero las credenciales no valen desde aquí.
Aplica a:MySQLMariaDBAurora
Este error es buena noticia a medias: significa que la red funciona y el servidor está vivo. Lo que falla es la identidad.
Tres causas, y se arreglan de forma distinta:
- La contraseña o el usuario no son los que el servidor espera. Revísalos en el gestor de conexiones. Ojo con los espacios al principio o al final al pegar una contraseña.
- La cuenta existe pero no desde este equipo. En MySQL y MariaDB una cuenta es el par usuario + host de origen: dba@localhost y dba@% son cuentas distintas con contraseñas distintas. Si conectas por túnel SSH, el servidor te ve llegar desde localhost; sin túnel, desde tu IP. Es la causa más frecuente de «me funciona en un sitio y en otro no».
- La cuenta no tiene permiso sobre la base concreta. Si el mensaje nombra una base de datos, el usuario entró pero no puede usarla; falta un GRANT sobre ella.
El Administrador de usuarios enseña, para cada cuenta, desde qué hosts puede conectarse y qué privilegios tiene.
O se borró, o se renombró, o tu cuenta no puede verla.
Aplica a:MySQLMariaDBAurora
Calíope recuerda la última base de datos que usaste en cada perfil, así que este error suele salir al reconectar contra un servidor que ha cambiado.
Qué mirar:
- Mayúsculas y minúsculas. En Linux los nombres de base de datos distinguen mayúsculas por omisión; en macOS y Windows, no. Una base creada en un portátil y buscada en un servidor Linux puede no encontrarse por eso.
- Permisos. Una cuenta sin privilegios sobre una base no la ve en la lista, así que «no existe» y «no puedes verla» se parecen mucho desde aquí. Si otro usuario sí la ve, es esto.
- El servidor equivocado. Con varios perfiles parecidos es fácil estar mirando el de producción creyendo que es el de pruebas.
Actualiza el árbol de esquema para ver la lista real que devuelve el servidor ahora mismo.
Palabras clave: base de datos, no existe, esquema, permisos, 1049
Se cortó a mitad de una operación: por qué pasa y qué queda a medias.
Aplica a:MySQLMariaDBAurora
La conexión estaba establecida y se cayó. Lo importante no es reconectar —eso es fácil— sino saber qué quedó a medias.
Si estaba corriendo una sentencia de escritura sin transacción explícita, puede haberse aplicado entera, en parte o nada, según dónde se cortara. El registro de consultas te dice cuál fue la última que salió; compruébala en el servidor antes de repetirla.
Causas habituales:
- Tiempo de espera del servidor. Una conexión inactiva más de wait_timeout (8 horas por omisión, pero muchos servidores lo bajan a minutos) se cierra sola. Se manifiesta como «se cayó justo cuando volví a la app».
- Una consulta que tarda más de lo permitido. Ahí lo que se agota es net_read_timeout o un límite del proxy que haya en medio.
- Un paquete demasiado grande. Un INSERT que supera max_allowed_packet cierra la conexión en vez de devolver un error legible.
- La red. Cambiar de wifi, suspender el equipo o una VPN que se reconecta cortan la conexión sin aviso.
Autenticación SSH fallida: clave, contraseña y el caso del segundo dispositivo.
El túnel llegó al servidor SSH pero no pudo identificarse. La base de datos ni se ha intentado todavía.
El caso que más despista: acabas de configurar el otro dispositivo. Los perfiles se sincronizan por iCloud, pero el permiso para leer tu archivo de clave privada no, y no es un olvido: ese permiso es una referencia al sistema de archivos de un equipo y en otro no significa nada. En el dispositivo nuevo hay que volver a seleccionar el archivo de clave en el perfil. Es la causa número uno de «el mismo perfil funciona en el Mac y no en el iPad».
Lo demás, por orden:
- El usuario SSH no es el de la base de datos. Son dos identidades distintas y a menudo distintos nombres.
- La clave pública no está en el servidor. Tiene que figurar en ~/.ssh/authorized_keys de ese usuario, en esa máquina.
- Permisos del archivo en el servidor. Un authorized_keys legible por otros hace que el servidor lo ignore en silencio, sin decir por qué.
- La frase de contraseña de la clave. Si la clave está protegida, hay que escribirla; una clave protegida sin frase se comporta igual que una clave equivocada.
Cuándo es normal, cuándo no, y cómo comprobarlo antes de aceptar.
La primera vez que te conectas a un servidor SSH, Calíope guarda la huella de su clave. Si en una conexión posterior el servidor presenta otra, se detiene y avisa.
Este aviso no es una molestia burocrática. Un cambio de clave es exactamente lo que se ve cuando alguien se ha interpuesto entre tu equipo y el servidor: acepta la clave nueva y le estarías entregando tus credenciales sin enterarte.
Cuándo el cambio es legítimo:
- Se reinstaló el sistema operativo del servidor.
- Se recreó la máquina virtual o el contenedor.
- El nombre o la IP se reasignaron a otra máquina (frecuente en la nube).
Cómo comprobarlo bien: pide la huella a quien administra la máquina, por un canal distinto de la propia conexión —un mensaje, una llamada—, y compárala con la que enseña el aviso. Si coincide, acepta. Si no puedes comprobarla, no aceptes.
Palabras clave: ssh, host key, huella, seguridad, man in the middle
Formatos admitidos y por qué el archivo deja de leerse solo.
Calíope lleva su propia implementación de SSH y no usa el ssh del sistema, así que admite un juego concreto de formatos: claves ed25519 y ECDSA en formato OpenSSH.
Si el archivo existe pero no se lee:
- Puede que el permiso haya caducado. Calíope solo accede a los archivos que eliges tú en un diálogo, y ese permiso se guarda como una referencia que a veces deja de valer: si mueves el archivo, renombras la carpeta o restauras el equipo desde una copia, hay que volver a seleccionarlo.
- Puede ser una clave RSA antigua. Conviértela a ed25519, que además es más rápida y más corta.
- Puede que hayas seleccionado la clave pública. El archivo es el que no termina en .pub.
- Puede estar protegida con frase de contraseña. Entonces hay que escribirla al conectar; sin ella no se puede descifrar y el resultado es indistinguible de un archivo ilegible.
Se cae cada pocos minutos: casi siempre es el servidor cerrando sesiones inactivas.
El túnel estaba abierto y dejó de estarlo. Reconectar el perfil lo arregla, pero si pasa a menudo hay una causa concreta que se puede quitar.
Lo más frecuente es el propio servidor SSH cerrando sesiones inactivas. Muchos sshd llevan ClientAliveInterval y ClientAliveCountMax configurados para desconectar a los pocos minutos sin tráfico. Como una sesión de trabajo con una base de datos tiene ratos largos de lectura sin enviar nada, el túnel se cae justo cuando vuelves a la app.
Otras causas:
- El equipo se suspendió. Al despertar, las conexiones de red que había ya no valen.
- Cambio de red. Pasar de wifi a cable, o de una wifi a otra, cambia la dirección de origen y corta la sesión.
- Un límite de sesiones simultáneas en el servidor, si varias personas usan el mismo usuario SSH.
El panel de Actividad enseña el túnel como un modo encendido mientras esté vivo, así que ahí se ve de un vistazo si sigue abierto.
Qué necesita Calíope de iCloud y qué deja de funcionar sin él.
Calíope usa iCloud para llevar tus perfiles, tus preferencias y —si lo activas— tus registros de un dispositivo a otro. Sin cuenta activa, todo eso se queda local.
Qué comprobar:
1. Que has iniciado sesión en iCloud en Ajustes del sistema.
2. Que iCloud Drive está activado, no solo la cuenta.
3. Que Calíope aparece en la lista de apps con iCloud Drive permitido. Es fácil pasarlo por alto: la cuenta puede estar bien y la app desmarcada.
No se pierde nada mientras tanto. Todo sigue guardado en este dispositivo; lo que no ocurre es la copia al otro. En cuanto iCloud vuelva, la sincronización se pone al día sola.
Un fallo de subida no pierde datos; qué hacer si se repite.
Lo primero: no se ha perdido nada. Todo lo que Calíope sincroniza tiene su copia en este dispositivo, y la subida es una copia adicional. Un fallo aquí significa que el otro dispositivo verá los datos más tarde, no que se hayan borrado.
Si ocurre una vez y no vuelve, casi siempre fue la red. Se reintenta solo.
Si se repite:
- Comprueba el espacio de tu cuenta. iCloud lleno da este error de forma constante.
- Mira si hay demasiadas escrituras seguidas. Calíope agrupa los envíos en lotes precisamente para no chocar con el límite de frecuencia de iCloud, pero una primera subida de un registro muy grande puede tardar varios intentos.
- Desactiva y reactiva la sincronización de lo que falla. Al reactivarla se vuelve a subir todo desde cero.
Antes de tocar nada, haz una copia. Preferencias tiene una exportación de la configuración completa; existe porque una activación de sincronización mal hecha puede reemplazar el archivo de conexiones del contenedor por uno vacío. Es un incidente medido, no una hipótesis.
Palabras clave: icloud, sincronización, error, reintentar, copia de seguridad
Qué ocupa espacio en Calíope y qué se puede recortar sin perder nada importante.
Calíope guarda muy poco en iCloud por omisión: tus perfiles de conexión y tus preferencias ocupan unos pocos kilobytes.
Lo que crece con el uso son los registros, y solo si los activas: el registro de consultas y el registro de errores. Los dos tienen retención configurable en Preferencias, y bajarla es la forma más directa de recuperar espacio sin perder nada que estuvieras mirando.
Qué recortar, por orden de efecto:
1. Los días de retención del registro de consultas. Es lo que más crece, con diferencia: guarda el texto completo de cada sentencia.
2. Los días del registro de errores.
3. El historial del asistente IA, si lo tienes sincronizado.
Vaciar cualquiera de los tres desde su propia herramienta borra también la copia de iCloud, así que el espacio se recupera de verdad y no vuelve en la siguiente sincronización.
Nada de esto afecta a tus datos de trabajo: las bases de datos viven en sus servidores y Calíope no las copia a iCloud nunca.
Cómo funciona el acceso a archivos en una app de la App Store.
Calíope corre en un entorno aislado, que es requisito de la App Store: no puede abrir un archivo por su ruta, solo aquellos que tú eliges explícitamente en un diálogo de abrir o guardar.
Eso tiene una consecuencia práctica que sorprende la primera vez: escribir la ruta a mano no basta. Aunque el archivo exista y sea tuyo, si no ha pasado por un diálogo, la app no lo ve.
Cómo se concede el permiso: abre el archivo o la carpeta con Abrir… o Guardar como…. A partir de ahí Calíope guarda el permiso y puede volver a usarlo sin preguntar.
Cuándo hay que volver a concederlo:
- Si mueves o renombras el archivo o su carpeta.
- Si restauras el equipo desde una copia de seguridad.
- Si es otro dispositivo. Estos permisos no se sincronizan a propósito: en otro equipo no significan nada.
Es la misma razón por la que una clave privada de SSH o una carpeta de respaldos programados hay que volver a seleccionarlas en cada dispositivo.
Por qué un archivo que antes funcionaba deja de abrirse sin que tú hayas tocado nada.
Cuando eliges un archivo en un diálogo, Calíope no guarda su ruta: guarda un permiso de acceso, una referencia que el sistema emite y que puede caducar. Cuando caduca, la app deja de poder abrir el archivo aunque siga en el mismo sitio.
Qué lo invalida:
- Mover, renombrar o volver a crear el archivo.
- Renombrar cualquier carpeta de su ruta.
- Restaurar el equipo desde una copia de seguridad.
- Que el archivo esté en un volumen externo o de red que se desmontó.
Y hay un caso que no es un fallo, sino una regla: estos permisos no se sincronizan entre dispositivos, y no por descuido. Un permiso así es una referencia al sistema de archivos de un equipo concreto; en otro no apunta a nada, y llevarlo produce fallos que no tienen ninguna explicación visible —típicamente, una autenticación SSH que falla sin motivo aparente.
La solución siempre es la misma: vuelve a seleccionar el archivo. No pierdes nada más; solo hay que concederle el acceso otra vez.
Qué intercepta, por qué, y cómo ejecutarla igualmente si estás seguro.
El modo seguro mira las sentencias antes de enviarlas y detiene las que pueden destruir datos de forma irreversible: DROP, TRUNCATE y los DELETE o UPDATE sin cláusula WHERE.
No es una restricción de permisos. Tu cuenta puede hacerlo perfectamente; lo que hace el modo seguro es obligarte a confirmar que era eso lo que querías. Está pensado para el error de un segundo: el DELETE al que se le quedó fuera el WHERE porque lo seleccionaste a medias antes de ejecutar.
Para ejecutarla igualmente, desactiva el modo seguro en la barra del editor SQL y vuelve a lanzarla. El interruptor está a la vista, no escondido en preferencias, justamente para que apagarlo sea un acto consciente y momentáneo.
Consejo de uso: déjalo encendido en los perfiles de producción y apagado en los de desarrollo. La configuración es por perfil, así que no hay que estar recordándolo.
Palabras clave: modo seguro, safe mode, drop, delete, where, protección
Dónde se pone, dónde se guarda y por qué no viaja con los ajustes.
Dónde está: Calíope › Preferencias › Asistente AI
El asistente SQL usa un proveedor externo, y hace falta una clave de API tuya para hablar con él. Se pone en Preferencias › Asistente AI.
Dónde se guarda: en el Llavero del sistema, no en un archivo de la app. Eso significa que ni el respaldo de configuración ni la sincronización normal se la llevan por defecto: un secreto solo sale de aquí si tú lo pides explícitamente y lo cifras con una contraseña que eliges en ese momento.
Si acabas de configurar otro dispositivo y el asistente no funciona ahí, es esto: hay que introducir la clave en cada dispositivo, o activar la sincronización del Llavero en Preferencias.
Calíope no intermedia en esa relación. La clave es tuya, va directa a tu proveedor y el consumo se factura en tu cuenta. Por eso los límites de uso y el saldo se gestionan en el panel del proveedor y no aquí.
Palabras clave: api key, clave, asistente, ia, llavero, proveedor
Límites de uso del proveedor y qué se puede ajustar desde Calíope.
La cuota no la impone Calíope: la impone el proveedor de IA que hayas configurado, según tu plan y tu saldo.
Dos límites distintos que dan el mismo error:
- Frecuencia. Demasiadas peticiones en poco tiempo. Se pasa esperando un minuto.
- Consumo. Se agotó el crédito o el cupo del periodo. Ahí hay que reponerlo en el panel del proveedor.
Qué se puede ajustar aquí: en Preferencias › Asistente AI puedes bajar el máximo de tokens por respuesta, que es lo que más consume, y cambiar a un modelo más económico. Una conversación larga también cuesta más, porque el historial viaja con cada petición: empezar una conversación nueva reduce el coste de las siguientes.
El resto del programa sigue funcionando igual. El asistente es una herramienta más; nada de lo que hagas con el editor SQL, los respaldos o los catálogos depende de él.
La base queda en un estado intermedio: cómo saber dónde se paró y qué hacer.
Dónde está: Espacio de Trabajo › Herramientas › Respaldo
Aplica a:MySQLMariaDBAurora
Una restauración aplica el archivo sentencia a sentencia. Si se detiene, lo aplicado hasta ese punto está aplicado: la base no vuelve sola al estado anterior.
Lo primero: no la des por buena. Una base a medio restaurar tiene tablas completas, tablas vacías y tablas que no existen, y a simple vista puede parecer que funciona.
Dónde mirar: el detalle técnico del error dice en qué sentencia se paró. Suele ser una de estas tres cosas:
- Una tabla que ya existía. Restaurar sobre una base que no estaba vacía choca en el primer CREATE TABLE repetido.
- Un DEFINER que no existe en este servidor. Vistas, rutinas y triggers llevan el usuario que los creó; si esa cuenta no existe aquí, fallan. Calíope quita esa cláusula al generar sus respaldos, pero un archivo hecho con otra herramienta puede traerla.
- Un límite de tamaño de sentencia. Un respaldo hecho contra un servidor con max_allowed_packet alto produce sentencias que un servidor con el valor por omisión rechaza.
Cómo salir: lo más limpio es borrar la base y restaurar de cero sobre una vacía. Reanudar desde la mitad exige saber exactamente qué se aplicó, y el archivo no lleva esa información.
Palabras clave: restaurar, respaldo, definer, max_allowed_packet, a medias