TOPIC: existing rrd files begin prompt for DB connection

existing rrd files begin prompt for DB connection 14 Jun 2016 23:15 #2299

  • XBAdmin
  • XBAdmin's Avatar
  • Offline
I am new to Logicity and to Crystal Reports...but have been developing MSAccess applications for over 20 years.
After building a few CR's and using Solution builder for our employees to view the reports,,,everything was running fine for weeks. Then today when any user attempts to open the .rrd file they are prompted for the Login ID and Password. If they know the sign in info they can un-check the embedded security box and the data populates the report for viewing. It is odd how everything was running fine for old and new reports alike and then they just changed.
My development machine has a full version of CR 2013 installed and if I go to run the .rrd file like everyone else I get the report as it should be, no prompt. We are linked to SQL Server 2008 R2 running Visual Manufacturing. Each user station is set up with Logicity 1.8.8 and ODBC .

I have been reading all day on the forum for solutions with no success. I look forward to working with everyone.

Thanxx,
Alan
The administrator has disabled public write access.

existing rrd files begin prompt for DB connection 12 Jul 2016 15:34 #2337

  • Beech
  • Beech's Avatar
  • Offline
I am having the same problem with Access 2013 being the backend database. Prior to splitting the DB the CRs would run now I get the login request. Any ideas. I am thinking it might have to do with Trust Settings i.e. Trust Location. Will try next.
The administrator has disabled public write access.

existing rrd files begin prompt for DB connection 02 Aug 2016 14:27 #2351

  • Beech
  • Beech's Avatar
  • Offline
Hi Allan:
I am having the same problem. I am using CR 2011 and have created a number of reports that access an Access 2013 ACCDE database that accesses that back-end database. I can run all of the reports no problem. It is when the user runs the report that they get the prompt with a user name and asking for a password, which there isn't one.
Have you had any success tracking down and solving this problem? I have left messages and emails with Sales and Support without any action.

Any help would be appreciated.
Thanks,
Dwight
The administrator has disabled public write access.

existing rrd files begin prompt for DB connection 09 Aug 2016 13:15 #2370

  • RonMoses
  • RonMoses's Avatar
  • Offline
Does the machine running Logicity have an ODBC connection that matches the name of the connection the report was based on?
The administrator has disabled public write access.

existing rrd files begin prompt for DB connection 11 Aug 2016 15:27 #2379

  • XBAdmin
  • XBAdmin's Avatar
  • Offline
I would like to start off with,,,,thank you all for joining in..
Here is a brief summary of the debug process going on or at least where I have left off.
1. It appears that at some point only some of the reports started prompting for the login info, not all of the reports.
2. My PC, which is the report design workstation runs Windows7 Pro, CR2013, using an ODBC DSN linked to a SQLServer Database on our Domain. All workstations that run the reports are using Logicity to view the reports and also have the ODBC setup on those stations. Again, they are running most of the reports just fine, so it is not the ODBC connection.
3. When I am logged in to my account at my station, all reports run fine. When I switch users on the same machine, as another user that cannot run the reports, I can NOT run the same reports that they cannot run on their station. So I am thinking permission on the Domain AD(active directory). As a test, I gave this other user Administrator rights on the domain and now they can run the reports, but I cannot have everyone being the Network Administrator, right? ...LOL So yes, I removed their Admin permissions.
4. When I build a new CR based on a SqlServer View, the User gets the prompt; however, if I open one of the reports that the User CAN open in design mode, save as another file name, attach the new SSView and remove the old SSView, place new fields from the new SSView, save and create a new .rrd file, the User CAN open the file without the prompt message.
5. So the current fix would be to create a template in CR from one of the "good" files and whenever I generate a new report, open the template and attach the new SSView, then finish the report as usual. This method has worked thus far but still does not explain why things changed.
6. The only other fix I can try is un-install and re-install CR on my station.

Any other ideas or questions would be great if you see something that I have missed.
Thanxx,
Alan
The administrator has disabled public write access.

existing rrd files begin prompt for DB connection 11 Aug 2016 15:33 #2380

  • XBAdmin
  • XBAdmin's Avatar
  • Offline
I would like to start off with,,,,thank you all for joining in..
Here is a brief summary of the debug process going on or at least where I have left off.
1. It appears that at some point only some of the reports started prompting for the login info, not all of the reports.
2. My PC, which is the report design workstation runs Windows7 Pro, CR2013, using an ODBC DSN linked to a SQLServer Database on our Domain. All workstations that run the reports are using Logicity to view the reports and also have the ODBC setup on those stations. Again, they are running most of the reports just fine, so it is not the ODBC connection.
3. When I am logged in to my account at my station, all reports run fine. When I switch users on the same machine, as another user that cannot run the reports, I can NOT run the same reports that they cannot run on their station. So I am thinking permission on the Domain AD(active directory). As a test, I gave this other user Administrator rights on the domain and now they can run the reports, but I cannot have everyone being the Network Administrator, right? ...LOL So yes, I removed their Admin permissions.
4. When I build a new CR based on a SqlServer View, the User gets the prompt; however, if I open one of the reports that the User CAN open in design mode, save as another file name, attach the new SSView and remove the old SSView, place new fields from the new SSView, save and create a new .rrd file, the User CAN open the file without the prompt message.
5. So the current fix would be to create a template in CR from one of the "good" files and whenever I generate a new report, open the template and attach the new SSView, then finish the report as usual. This method has worked thus far but still does not explain why things changed.
6. The only other fix I can try is un-install and re-install CR on my station.

Any other ideas or questions would be great if you see something that I have missed.
Thanxx,
Alan
The administrator has disabled public write access.

existing rrd files begin prompt for DB connection 18 Aug 2016 17:57 #2388

  • RonMoses
  • RonMoses's Avatar
  • Offline
This still sounds to me like a mismatch in ODBC DSN names. For example, let's say all those working reports were created by someone who used an ODBC connection called "OurData". Logicity is going to be looking for an ODBC connection on its local machine called "OurData". So long as that's there, Logicity should be able to use it with the username/password embedded in the RRD.

Now let's say you create a new report but your ODBC connection is called "MyData". The Logicity machine doesn't have a connection with that name, so it prompts. Now...we also have to consider the difference between user and system DSNs. If you have a user DSN called "MyData", it will work. But if you log into the machine under a different user account, and that user doesn't have a "MyData" connection, same problem.

I think the views are a red herring. I see a scenario where you create a report with the "MyData" connection, and it doesn't work for the reasons stated above. You then open an older report that works (possibly because it was created with the "OurData" connection?) and swap out the views. The ODBC data source is the same, so it works.

This is all very hypothetical, but there's a way you can test the theory. Open one of the reports that works and select Database > Set Datasource Location. Make a note of the data source name. Now do the same on a report that doesn't work. If it's different, you probably have your culprit.

And if it's not... well at least I didn't make it any worse. :)
The administrator has disabled public write access.