Avalados por :
Olá!
Encontrei isso no site de um cliente e pesquisei muito no Google, mas encontrei pouca informação. O cenário é o seguinte: A versão antiga do aplicativo era CR9. A nova versão do aplicativo é CR XI R2 Sp6, .NET. O aplicativo é de 32 bits. O ambiente de desenvolvimento antigo era XP com um banco de dados Access. Os clientes são tanto de Access quanto de MS SQL Server. O novo ambiente de desenvolvimento é Win7 de 64 bits.
Apenas um cliente recebeu o erro 4060. Estava no Xp de 32 bits. Apenas dois relatórios mostraram o erro e descobri que havia mudado o banco de dados do relatório do padrão do Access para um DSN de arquivo que apontava para um banco de dados SQL enquanto corrigia alguns erros.
Mudar o banco de dados do relatório para um DSN do sistema que apontava para um banco de dados SQL não resolveu o problema, mas mudá-lo para um DSN de banco de dados Access sim!
Então, o que resolveu o problema foi abrir o relatório, Banco de dados, Configurar banco de dados (segundo item do menu de cima) e apontar para outro DSN. Salvar o relatório. Copiá-lo para o PC do cliente e agora foi relatado corretamente nessa máquina, contra um banco de dados SQL.
O que me deixa confuso é por que isso aconteceu? Ou seja, o próprio aplicativo muda a conexão do banco de dados ao executar o relatório, no entanto, o DSN antigo importava? O relatório NÃO está configurado para salvar dados com o relatório.
Olá Anders
Muito obrigado por compartilhar sua solução. Nunca são demais, sempre é bom ter diferentes perspectivas.
Tenha um ótimo dia,
- Ludek
"Erro 4060 - O servidor recusou a conexão; o acesso ao banco de dados selecionado foi negado."
Ah... Então o erro vem do SQL Server e não do CR. Deveria ter adivinhado. Agora sei o que procurar em seguida. No entanto, não poderia ter sido um erro de permissão, pois o mesmo erro ocorreu se eu fizesse login como 'sa'.
O mais provável é que seja algo relacionado com 64/32 bits.
Eu sei sobre o arquivo DSN e CR, então o aplicativo criará um DSN de sistema programaticamente, apenas para o CR, se um não existir. Curiosamente, não funcionou se eu salvasse o arquivo rpt com um banco de dados selecionado como um DSN de sistema do SQL Server, mas funcionou se eu salvasse o RPT com um banco de dados selecionado como um DSN de sistema do Access.
O que aconteceu neste caso foi que conectei o relatório (no designer) a um banco de dados específico, como uma medida de solução de problemas, e esqueci de mudar de volta para o "modelo". Aparentemente, o CR salva algo no arquivo RPT e aparentemente isso não é apagado quando um banco de dados é selecionado a partir do aplicativo.
De qualquer forma, agora está funcionando e a razão pela qual postei aqui é que encontrei toneladas de perguntas semelhantes na web, principalmente em outros fóruns, como os da Microsoft, então pensei que postar isso poderia ajudar alguém se ele se deparar com o mesmo problema.
.
bool rc = CheckDatasource(dsn);
if(!rc)
{
rc = SQLConfigDataSource(NULL, ODBC_ADD_DSN, theApp.m_DatabaseDriver, parms);
if(!rc)
{
message.Format("Não foi possível criar o origem de dados %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; // Precisa ser uma fonte de dados de 32 bits criada com C:WindowsSysWOW64odbcad32.exe
crConnectionInfo->DatabaseName = ss_database;
//
crConnectionInfo->UserID = ss_user;
crConnectionInfo->Password = ss_pw;
//
// Conexão segura?
//
if (theApp.m_DatabaseTrusted) crConnectionInfo->IntegratedSecurity = true;
break;
}
//
// Obter informações da tabela do relatório
crDatabase = m_Report->Database;
crTables = crDatabase->Tables;
// Percorrer todas as tabelas no relatório e aplicar as informações de conexão para cada tabela.
for (int i = 0; i < crTables->Count; i
Olá Anders
Difícil de dizer. Qualquer número de variáveis (ou combinação delas) poderia ter sido a causa. Por exemplo:
1) DSN de 32 bits vs 64 bits (Existem duas versões do ODBC em um servidor de 64 bits.)
2) Cliente de banco de dados
3) Nunca use DSN de arquivo, sempre use DSN de sistema com CR
4) Procurar o erro na documentação do banco de dados também poderia ter ajudado:
Erro 4060 - O servidor rejeitou a conexão; O acesso ao banco de dados selecionado foi negado.
Por exemplo, poderia haver falta de permissões de execução em algum objeto no banco de dados SQL e não no banco de dados de Access(?)
E assim por diante...
Ludek
Siga-nos no Twitter http://twitter.com/SAPCRNetSup
Tem ideias para melhorar? Experimente [SAP Idea Place|https://ideas.sap.com/community/products_and_solutions/crystalreports]
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
