Conexiones a TRIVASADB — qué servidor usar para qué

Hay tres copias de la base del ERP MPRO, mismo motor SQL Server, con distinto rol y frescura. Usar la copia equivocada no da un error — da datos truncados o desfasados de forma silenciosa, así que confirmar cuál corresponde antes de cualquier exploración o pipeline nuevo.

Host	Base	Rol	Frescura
192.168.117.200	TRIVASADB (sin el 3)	Copia desactualizada	Nunca usar — confirmado con datos truncados (Consumo_Interno casi vacío en un filtro a enero 2026 que debía traer cientos de filas)
192.168.117.200	TRIVASADB3	Copia viva pero no productiva	Al día para la mayoría de propósitos; sirve de respaldo para cargas masivas sin pegarle a producción
192.168.117.207	TRIVASADB	Base en vivo de producción	La fuente de verdad para todo lo que necesite el dato más reciente
192.168.117.204	TRIVASADB	Usada puntualmente (.dlt/secrets.toml, algunos pipelines/pruebas)	Sin confirmar su relación exacta con .207 — ver “Abierto” abajo

Cómo se descubrió

Un query filtrado a enero 2026 sobre Consumo_Interno, usando la conexión original del repo (connection.py → .200/TRIVASADB), regresó casi vacío. Se creó connection_200_trivasadb3.py (mismo patrón: pymssql + SQLAlchemy + credencial vía Bitwarden, no hardcodeada) apuntando a .200/TRIVASADB3, que sí tiene datos vivos hasta la fecha de exploración. Cualquier código que necesite datos actuales debe usar esa conexión (o .207 directo), no connection.py.

Patrón de uso en los pipelines dlt

.200/TRIVASADB3 se usa para cargas iniciales masivas (backfill de todo el histórico), .207 para sincronización incremental continua — evita hacerle un full-scan sin filtro reciente a la base transaccional real. Detalle completo en Pipelines dlt.

Abierto / pendiente

• No está confirmada la relación exacta entre .200/TRIVASADB (sin el 3), .200/TRIVASADB3, .204 y .207 — podrían ser 3+ copias con distinto nivel de actualización entre sí, más allá del caso confirmado de .200/TRIVASADB desactualizada.
• Antes de depender de un cutover automático de backfill (.200/TRIVASADB3) a incremental (.207) para una tabla nueva, hay que validar manualmente que .200/TRIVASADB3 no esté desfasada respecto a .207 en el rango de fechas relevante — si lo está, el cursor de incrementalidad heredado deja huecos sin avisar.
• Pendiente decidir si connection.py (que sigue apuntando a la copia desactualizada) se corrige, se retira, o solo se documenta su propósito para que nadie lo use por error.

Véase también

• Modelo de datos TRIVASADB
• Pipelines dlt — usa esta tabla de servidores para decidir origen de backfill vs incremental.
• DBHub — servidor MCP que expone .200/TRIVASADB3 de solo lectura a Claude chat; usa esta misma tabla para justificar por qué esa copia y no .207 (producción).