Preguntas frecuentes

No. Cuando presionas Formatear, tu SQL se envía a nuestro servidor, se formatea en memoria y se devuelve en la misma respuesta. No se escribe en una base de datos, en un archivo ni en un log, y no se comparte con socios de analítica ni de publicidad. Aun así, usa cualquier herramienta en línea con cuidado: no pegues credenciales, datos de clientes ni nada que no tengas permitido compartir. La página de privacidad describe todo lo que el sitio sí registra.

Es gratuito y no hay cuenta, registro ni inicio de sesión. Abres el formateador, pegas tu SQL y lo formateas. El sitio muestra anuncios, que se describen en la página de privacidad.

Sí. Las cookies esenciales recuerdan tu idioma, tu tema y tu elección sobre cookies. Una cookie de identificador de sesión se crea solo después de que eliges "Aceptar todas" o "Solo esenciales"; no tiene una fecha de caducidad fija, es la misma en todas las páginas que abras y se usa solo para agrupar visitas en el contador de visitas. Las cookies de Google Analytics se crean solo si eliges "Aceptar todas" en el banner de cookies, y los anuncios de Google AdSense se solicitan como no personalizados hasta que lo hagas. Puedes cambiar tu elección en cualquier momento con el enlace "Preferencias de cookies" del pie de página. Los detalles están en la página de privacidad.

Sí. Presiona Ctrl+Enter, o ⌘+Enter en una Mac, mientras el editor tiene el foco. El botón Copiar pone el resultado en tu portapapeles y Limpiar vacía el editor. La barra de estado debajo del editor muestra la cantidad de líneas y caracteres, y la línea y columna actuales.

Hasta 20.000 líneas por solicitud. Una entrada más grande se rechaza con un mensaje en lugar de cortarse. Para scripts más grandes, divídelos en archivos de unos pocos miles de líneas, que además son más fáciles de revisar.

Sí. La entrada se divide en los puntos y coma y cada sentencia se formatea en orden, así que un script de migración o un lote de consultas vuelve con todas las sentencias organizadas de la misma manera.

El formateador está diseñado para cambiar solo espacios en blanco, saltos de línea y mayúsculas/minúsculas de las palabras clave. Los literales de cadena, los identificadores entre comillas y los comentarios quedan como están, al igual que los nombres calificados como t.month. Un punto a tener en cuenta: cualquier palabra simple y sin comillas que coincida con una palabra clave de SQL cambia de mayúsculas/minúsculas, incluido un nombre de columna o alias como month, que se convierte en MONTH con palabras clave en mayúsculas. La mayoría de las bases de datos no distinguen mayúsculas de minúsculas en los nombres sin comillas, pero si la tuya sí lo hace, califica esos nombres o ponlos entre comillas. Como con cualquier herramienta que reescribe código, revisa el resultado antes de ejecutarlo en producción.

Sí. Tanto los comentarios de línea -- como los comentarios de bloque /* */ se conservan en la salida, y su texto no cambia de mayúsculas/minúsculas.

Son cinco. Espacios de sangría (4 por defecto) define la profundidad de cada nivel de anidamiento, y las tabulaciones de la entrada se reemplazan por esa cantidad de espacios, salvo dentro de literales de cadena e identificadores entre comillas. Cantidad máxima de columnas (120 por defecto; 0 la desactiva) divide las líneas que siguen siendo demasiado largas. Comas coloca las comas después de un elemento (el valor predeterminado) o antes del siguiente. Palabras clave escribe las palabras clave en mayúsculas (el valor predeterminado) o en minúsculas. Paréntesis en nueva línea (desactivada por defecto) mueve a su propia línea el paréntesis de apertura de un bloque con sangría, como una subconsulta.

Es la convención más usada en las guías de estilo y en la documentación de SQL. Las palabras clave en mayúsculas separan la estructura de una consulta (SELECT, FROM, WHERE) de los nombres de tus tablas y columnas, lo que ayuda cuando recorres una sentencia larga. Las minúsculas funcionan igual de bien si tu equipo las prefiere; lo que importa es ser consistente. La guía de estilo SQL trata esta y otras convenciones.

Cantidad máxima de columnas se aplica como un paso final, después de organizar el diseño. Cualquier línea más larga que el límite se corta en el último espacio antes de él, y la continuación recibe dos espacios adicionales de sangría. No reorganiza las cláusulas. Nunca corta dentro de un literal de cadena, un identificador entre comillas o un comentario, y cuando el corte va después de una coma, la coma se queda al final de la línea. Si un corte cae en un lugar incómodo, aumenta el límite o ponlo en 0 para desactivar el ajuste de línea.

No hay un selector de dialecto. Las reglas de diseño trabajan sobre el SQL que los dialectos tienen en común: SELECT, joins, subconsultas, CASE, DML y DDL. PostgreSQL recibe un tratamiento adicional para los casts con ::, los parámetros $1, los operadores de JSON y de arrays y los cuerpos entre dólares (dollar quoting). Los nombres entre comillas invertidas de MySQL y los nombres entre corchetes de SQL Server, como [dbo].[orders], se mantienen intactos y nunca cambian de mayúsculas a minúsculas ni viceversa. No hay un tratamiento específico para el separador de lotes GO ni para los bloques BEGIN … END fuera de las comillas de dólar de PostgreSQL, así que revisa esos scripts con más cuidado. Consulta diferencias entre dialectos SQL y la guía de formateo para PostgreSQL.

Las funciones de PostgreSQL y los bloques DO con cuerpo $$ reciben un diseño de PL/pgSQL: DECLARE, BEGIN, IF, ELSIF, LOOP, EXCEPTION y END se organizan como bloques. Los cuerpos de procedimientos en T-SQL y PL/SQL se formatean como una secuencia de sentencias simples, sin un diseño especial de bloques.

Usa la página de contacto. Incluye un fragmento pequeño de SQL que muestre el problema, las opciones que usaste y el resultado que esperabas. Quita cualquier nombre o valor confidencial antes de enviarlo.