I’ve created a report which uses an excel spreadsheet as one of the datasources. When run from crystal reports it works fine but when I try to run it from the infoview I get the error message: Unable to connect: incorrect log on parameters.
I tried changing the path of the spreadsheet in the CMC from X:\path\filename.xls to \server\path\filename.xls but then get: The database logon information for this report is either incomplete or incorrect.
There isn’t a password on the spreadsheet so I’m not sure what I’m doing wrong.
Does anyone have and ideas / help
Hello Smith,
did you find solution to this problem. I am having a similar issue, built a crystal reports using excel as a source. This excel is in my local drive and seems like that is the problem and i am not finding any solution on this.
So i can generate reports on my machine and manipulate the data using prompts but when i xport the data to infoview i cannot refresh the data or change the prompt and the error that i get is
“Failed to load database connection”
So if you know any solution to this please let me know. It will be really helpful.
It is very simple…first enter some data in excel…it should not be office2007 it should be office97-2003…if you have office 2007 then go to the file save as option and then save in 97-2003 format…
open crystal reports create new connection Access/Excel option then select the excel file and then change the database type from access to excel 8.0 it will display the tabs available in excel … then select the tab where you have the data… then press next and there you go…let me know still if you have problem…I will send you the screen shots…
Thanks for your suggestion. I’ve already linked the spreadsheet into my report and from crystal reports I can run the report fine.
The problem i’ve got is when I publish it into business objects and try to run it from there. I keep getting the error message The database logon information for this report is either incomplete or incorrect.
CAUSE 1:The report uses an ODBC connection to a Transoft U/SQL database. The root cause of the error messages seems to be when designing a report in Crystal Reports XI, the Transoft ODBC driver is prompting for an additional login input when using a trusted connection.
The additional logon prompt happening in Crystal Reports XI is visible but when running through InfoView or CMC the extra prompt dialogue box is probably being launched as a background process hence the requested information cannot be passed or entered and the error message appears.
RESOLUTION 1:In Crystal Reports XI, by checking or using a non-trusted connection while initial database connection, would allow the reports to run fine in Crystal Reports Server XI.
(or)
CAUSE 2:When publishing a report with dynamic prompts from the Designer, it needs to create a Business View and Prompt in the repository. The user does not have View, Edit and Set Security rights to perform this.
RESOLUTION 2:While running the reports it is directed to Database rather than universe.So logon information might be wrong.Pls contact your support team for some action for the above cause!
Hi there
I know I’m responding to a very old post but due to a Windows update this weekend we are now experiencing this issue whereby Crystal reports that are run through the scheduler with Excel (ancient Excel) as a data source fail with an invalid login error.
The version of crystal is - Crystal 2013 SP 5
Accessing Excel xls files not xlsx
Windows Server 2008 - BO XI 4.1 sp5
The SSIS guys in the business are also complaining that a Windows update mucked up their Microsoft JET Database Engine access and I’m wondering if it’s the same issue??
Any ideas??
Do I need to create an ODBC to the Excel?? and use that??
There is no way we will be allowed to roll back the Windows update
I understand the issue has been caused by Microsoft deprecating part of their connectivity software??
Is there a way to connect Crystal 2013 to an Excel spreadsheet and then run the report through the scheduler?
The issue doesn’t appear if I run the report locally on my machine.
I wonder whether installing Excel on the BO server would help - I’m scratching the bottom of the barrel with ideas here.
Thanks
I have and believe we still are using Excel as a data source. The only issue we have when we post to our BI 4.1 platform is the user that is used for the services on the BI platform has to have rights to where the Excel spreadsheet is.
For use it has been an issue since we have a Novell network and Microsoft does not play well with it. One of our brilliant programmers came up with a solution (do not ask me exactly what was done). But it overcomes an security issue.
Thanks for your response - I think this might be my issue … the access from the BO platform to the platform that holds the Excel file … but I am struggling to test it and prove it
The Server Intelligence Agent (SIA) that runs BusinessObjects is installed to, by default, use the “Local Service” account on the server where it is installed. Best practice is to change that to use a network service account that is outside of the password change rules that the regular network users have. With my clients I have seen this type of account setup to where either the password never expires or it only expires every 6 or 12 months.
If yours is set up using a network account, then that account needs to have “read” rights to the folder where the Excel file is located in order to be able to connect to the data. Also, when developing the report you need to use a full UNC path instead of a mapped drive when connecting to the file.
Hi all,
Update: This is resolved.
I managed to get it working using the OLEDB drivers and the FULL NETWORK path to the file that took me a day or so to figure out - thanks to everyone for their help!!
Changing to using the OLEDB allowed reports that weren’t working through the scheduler to start working.
We found that the Crystal reports ran fine locally on the user’s machines as they had the share drives etc set up correctly but when the Crystal reports were sent to the repository, they couldn’t resolve the network path and thus failed.
By changing the path of the source to use the full network path it meant that the server could find the required data and run the report.
Maybe if you promote a report from prod, where it’s working to Dev, were it’s not working you’ll get a view as to why it’s failing??
Is it the same reports in Dev and Prod but just te environment that’s different??
I’m sure you have done this already but finding the differences between the systems will be paramount to resolving your issue.
Thanks for your reply SarahG.
Yes I’ve tried all those suggestions. I’m thinking it now has to do with the Service account that is running the SIA (Server Intelligence Agent) on Dev server.
The attached SAP note mentions about the SIA and the account running it.
(BOB member since 2009-11-24)
(BOB member since 2005-08-22)
(BOB member since 2007-04-16)
that took me a day or so to figure out - thanks to everyone for their help!!
(BOB member since 2005-08-22)
totally.