Avalados por :
¡Hola!
Me encontré con esto en el sitio de un cliente y busqué mucho en Google, pero encontré muy poca información. El escenario es el siguiente: La versión antigua de la aplicación era CR9. La nueva versión de la aplicación es CR XI R2 Sp6, .NET. La aplicación es de 32 bits. El entorno de desarrollo antiguo era XP con una base de datos de Access. Los clientes son tanto de Access como de MS SQL Server. El nuevo entorno de desarrollo es Win7 de 64 bits.
Solo un cliente obtuvo ese error 4060. Estaba en Xp de 32 bits. Solo dos informes mostraron el error y descubrí que había cambiado la base de datos del informe de la predeterminada de Access a un DSN de archivo que apuntaba a una base de datos SQL mientras corregía algunos errores.
¡Cambiar la base de datos del informe a un DSN del sistema que apuntaba a una base de datos SQL no solucionó el problema, pero cambiarlo a un DSN de base de datos de Access sí lo hizo!
Entonces, ¿qué solucionó el problema fue abrir el informe, Base de datos, Establecer base de datos (segundo elemento del menú desde arriba) y apuntar a otro DSN. Guardar el informe. Copiarlo al PC del cliente y ahora se informó correctamente en esa máquina, contra una base de datos SQL.
Lo que me desconcierta es ¿por qué hizo esto? Es decir, ¿la aplicación misma cambia la conexión de la base de datos al ejecutar el informe, sin embargo, ¿importaba el DSN antiguo? El informe NO está configurado para guardar datos con el informe.
Hola Anders
Muchas gracias por publicar tu solución. Nunca hay suficientes de esas, siempre es bueno tener todo tipo de formas de ver las cosas.
Que tengas un gran día,
- Ludek
"Error 4060 - El servidor rechazó la conexión; se ha denegado el acceso a la base de datos seleccionada."
Ah... Así que el error proviene de SQL Server y no de CR. Debería haberlo adivinado. Ahora sé qué buscar a continuación. Sin embargo, no pudo haber sido un error de permiso, ya que el mismo error ocurrió si iniciaba sesión como 'sa'.
Lo más probable es que sea algo relacionado con 64/32 bits.
Conozco sobre el archivo DSN y CR, por eso la aplicación creará un DSN de sistema programáticamente, solo para CR si no existe uno. Curiosamente, no funcionó si guardaba el archivo rpt con una base de datos seleccionada como un DSN de sistema de SQL Server, pero funcionó si guardaba el RPT con una base de datos seleccionada como un DSN de sistema de Access.
Lo que sucedió en este caso fue que conecté el informe (en el diseñador) a una base de datos en particular, como medida de solución de problemas, y olvidé cambiar de nuevo al "modelo". Aparentemente, CR guarda algo en el archivo RPT y aparentemente eso no se borra cuando se selecciona una base de datos desde la aplicación.
De todos modos, ahora funciona y la razón por la que publiqué aquí es que encontré toneladas de preguntas similares en la web, principalmente en otros foros, como los de Microsoft, así que pensé que publicar esto podría ayudar a alguien si se encuentra con el mismo problema.
.
bool rc = CheckDatasource(dsn);
if(!rc)
{
rc = SQLConfigDataSource(NULL, ODBC_ADD_DSN, theApp.m_DatabaseDriver, parms);
if(!rc)
{
message.Format("No se pudo crear el origen de datos %s", dsn);
AfxMessageBox(message);
return false;
}
}
ss_dsn = gcnew String(dsn);
ss_database = gcnew String(theApp.m_DatabaseDatabase);
ss_user = gcnew String(theApp.m_Anvandarnamn);
ss_pw = gcnew String(theApp.m_Losen);
crConnectionInfo->ServerName = ss_dsn; // Necesita ser un origen de datos de 32 bits creado con C:WindowsSysWOW64odbcad32.exe
crConnectionInfo->DatabaseName = ss_database;
//
crConnectionInfo->UserID = ss_user;
crConnectionInfo->Password = ss_pw;
//
// ¿Conexión segura?
//
if (theApp.m_DatabaseTrusted) crConnectionInfo->IntegratedSecurity = true;
break;
}
//
// Obtener la información de la tabla del informe
crDatabase = m_Report->Database;
crTables = crDatabase->Tables;
// Recorrer todas las tablas en el informe y aplicar la información de conexión para cada tabla.
for (int i = 0; i < crTables->Count; i
Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
Hola Anders
Difícil de decir. Cualquier número de variables (o combinación de ellas) podría haber sido la causa. Por ejemplo:
1) DSN de 32 bits vs 64 bits (Hay dos versiones del ODBC en un servidor de 64 bits.)
2) Cliente de base de datos
3) Nunca use DSN de archivo, siempre use DSN de sistema con CR
4) Buscar el error en la documentación de la base de datos también podría haber ayudado:
Error 4060 - El servidor rechazó la conexión; Se ha denegado el acceso a la base de datos seleccionada.
Por ejemplo, podría haber falta de permisos de ejecución en algún objeto en la base de datos SQL y no en la base de datos de Access(?)
Y así sucesivamente...
Ludek
Síguenos en Twitter http://twitter.com/SAPCRNetSup
¿Tienes ideas de mejora? Prueba [SAP Idea Place|https://ideas.sap.com/community/products_and_solutions/crystalreports]
contacto@primeconsultor.com
+1 (305) 285-8622
© 2025 Todos los derechos reservados.
Desarrollado por Prime Consultor
