Crystal 8.5 XP pro distributed report ODBC will not connect to DB

[justauser2004]

Here is the situation which I am trying to fix:

1) I develop, compile, and distribute reports in CR8.5. I think I compile correctly.

2) I am running XP Pro and can run a compiled distributed report. I click on the dist rep icon and it takes about 4 seconds to draw the report parameter dialog box. I then select the parameters from the dist report dialog box and then select the print button. It takes about 5 seconds for the Logon Parameters dialog box to come up. I type in the database location and my log on info. It then runs the report. I am logged into my client as me and I am an administrator on the domain.

3) Another client is also on XP Pro, logs onto the domain as themselves-they are also an administrator- and when they press the print button on the distributed report, the log on parameters dialog box immediately comes up-this is the first indication the report will not process-the log on parameter dialog box pops up too quickly. They type in the info needed to connect via ODBC to the data source and the logon parameters dialog box flickers but does not connect. If I rt click the report's icon and run as me on the domain, it works like a charm!! I installed the bootstrap program I thought the client needed to run the report but that did not make the report work.

I have tried many things and now am at the point where I don't know what else to do-There was another XP Pro client who could not run the distributed reports either so I used her login and client as a test. I installed the bootstrap app you need to have on the client to run distributed reports and was able to run the dist report no problem on her PC with her log in. She is not an administrator on the domain-I do not even know if this makes a difference! I think I installed the bootstrap program as administrator on the local machine.

My log in and the other person's login works for these reports-the other person's just does not work.

Any idea what I did wrong in setting up the distributed report on her client? Does it have something to do with permissions in XP and the domain? Ugh. Any help would be greatly appreciated. Thanks

 

[synapsevampire]

WHat you're describing is the default error for connectivity, not a nad install.

Make sure that they're using the same ODBC name as you are, that's usually the problem.

If they don't have the ODBC set up correctly, or don't have permission to the objects Crystal will provide a generic sort of error for some databases. Since you didn't bother to state anything specific about databases I can't offer much more.

-k

 

[justauser2004]

Thanks for the response. I agree with your hypothesis, the connectivity is the issue, not a bad install. I just can't figure it out and it is frustrating!!

There is no error when I try to print with this persons user name-just no connection to the database when the database logon dialog box appears. I can tell immediately it will not work because of the response time between dialog boxes.

The database is a proprietary(sp) database developed some 25 years ago. It runs on Unix and is called Link-List-a name that was coined by the creator, I believe, of the application we are using. The newest version of the software is SQL but the one we are using is Linklist. The user can connect via ODBC to the database for everyday use-just not Crystal distributed reports. Grrr.

I have added a user DNS to the ODBC connections while I was logged on as him and that ODBC connection does not allow me to connect when running a distributed report but does work for the database connection for everyday use.

I don't quite understand your comment, ."..or don't have permission to the objects...". I gave him permissions to everything(I thought)-which I will have to change-hoping that would fix the problem.

Any thoughts on how to troubleshoot this from the beginning again? The user does not like people on his PC so sitting at his desktop for hours is not my first choice. I would like to test using his login on my client.

 

[MColeman]

Does the user have the correct version of the ODBC driver?

 

[justauser2004]

To MColeman and Synapsevampire:

Yes, it was the ODBC drivers. Here's the deal: I need to use my USER dsn to connect to the database via odbc. If I do not, I cannot use all the functionality of the application.

Crystal distributed reports likes to use a SYSTEM dsn to connect to the database. When the user who could not connect to the database through the distributed report, I discovered, with help, that the report was compiled in my crystal, on my client, with, you guessed it, my system dsn.

So, to fix the problem, I copied the .crf, .exe, and the.rpt files over to the client's c drive. I then loaded crystal onto the client and verified the database with the system dsn and saved the report. I then compiled it. Low and behold, it works! The only problem is if the report is changed, I need ta make sure I change the one on the client. My next project is the change all of the system dsn names to be equal and the user dsns to be equal on all workstations here. I'll then recompile the reports and they should all be usable from the network shared directory.

A curious thing happened after all this was figured out-I went in to change the permissions of the user to power user and got errors when I went back into try and run the distributed report. Since I spent many hours figuring the problem out, I decided to change the user back to the original permissions and that made the report work again. What was curious was I received errors but the report still printed after I clicked ok on the errors. Ahh-wonderful XP permissions....Those OBBC dsns are important, huh!?!

Thanks for your direction-I learned some very useful things about crystal. Why did they take the distribution functionality away besides to make more $$$$?