can't get an answer to a crystal rpt question re database connection - Cor, Herfried, Armin, Ken Tuc

[Bernie Yaeger]

I can't believe that there aren't lots of developers who:

1. create a crystal report that connects to sql server
2. calls the report using the crystalreportviewer control to view it and
then, if appropriate, print it
3. tries to deploy that report to the client's database, but now it calls
for a different database name

Yet I can't get an answer to the question:
I have developed numerous reports in an app (Windows Database App) that is
soon to go into production. When I built each report, CR connected to sql
server on my development platform. The connection string is different than
it will be at my client.

How can I change the connection string so that it recognizes my client's
server instead of mine for each of these reports?

Of course, I could install a version of crystal on the client and rebuild
the reports there, but that seems a terrible pain - and for every customer
with sql server? I've written to crystal and I get links to unhelpful kbase
articles.

Thanks for any help.

Bernie Yaeger

 

[Jorge Cavalheiro]

Hello Bernie

You can use the SQL-DMO ListAvailableSQLServers to
retrieve all SQL servers on your client. If there's only
one then use that one if not ask the user which one to
use.

And when you define the ConnectionInfo of the report you
can use .ServerName = <your variable>

Kind Regards
Jorge Cavalheiro

 

[Jorge Cavalheiro]

As addenda to what i say.

All MS SQL Servers have a Master database.

You can use the following command :
<code>
Use Master
exec sp_databases
</code>
That will return all databases on the server and there
size.

You still need to have the database admin password on
your client to run this.

Kind Regards
Jorge Cavalheiro

 

[Bernie Yaeger]

Hi Jorge,

Tx for your help; I think I'm in the right direction now.

Bernie

 

[Guest]

Bernie

I have gone through this, and the following code circumvents all of the known bugs that I worked through to resolve the problem. Apparently there are more obvious ways to handle this that simply don't work (or didn't when I wrote the code)

I store connection information in a 'Registration' dll file that is located on each client. That way I can have an identical application running on many different clients, and each uses it's own set of connection info to get to the appropriate server and database. You could also use application settings that the users can change themselves

With this in place, I can create or revise reports on my dev machine and simply copy the report file to any and all clients with no changes at all, which was the main goal. The clients do not need Crystal Reports, and you certainly don't have to build the reports for each client

One note: this particular method will not work if you use Windows Integrated Security to connect the report to the database on your dev machine. So, if you used Integrated Security, and you want to use this code, open each report, change the database connection to use a UserName & Password, and re-save it. I informed Crystal that it would be really nice if this could be changed at run-time, but I am not aware if they have accomplished this yet

Declarations..
Imports CrystalDecisions.Share
Imports CrystalDecisions.CrystalReports.Engin

...
'Pass connection inf
Dim crTableLogonInfo As New TableLogOnInf
Dim crConnectionInfo As New ConnectionInf
Dim crTable As Tabl
Dim subRepDoc As New ReportDocumen
Dim crSection As Sectio
Dim crReportObject As ReportObjec
Dim crSubreportObject As SubreportObjec
With crConnectionInf
.DatabaseName = <<Insert DatabaseName>
.ServerName = <<Insert ServerName or IP Address and Port>
.UserID = <<Insert UserID>
.Password = <<Insert Password>
End Wit
crTableLogonInfo.ConnectionInfo = crConnectionInf

'CurrentReport is the ReportDocument loaded from a file earlier in this subroutin
For Each crTable In CurrentReport.Database.Table
crTable.ApplyLogOnInfo(crTableLogonInfo
crTable.Location = crTable.Nam
Nex

'If you have any sub-reports, they need the connection info too..
For Each crSection In CurrentReport.ReportDefinition.Section
For Each crReportObject In crSection.ReportObject
If crReportObject.Kind = ReportObjectKind.SubreportObject The
crSubreportObject = CType(crReportObject, SubreportObject
subRepDoc = crSubreportObject.OpenSubreport(crSubreportObject.SubreportName
For Each crTable In subRepDoc.Database.Table
crTable.ApplyLogOnInfo(crTableLogonInfo
crTable.Location = crTable.Nam
Nex
End I
Nex
Nex

'ReportViewer is the Crystal Reports Forms viewer on my for
ReportViewer.ReportSource = CurrentRepor

I hope this prevents the same headaches that I had to go through to get here..

Best Regards
Mark Lauser - Crimson Software

 

[Bernie Yaeger]

Hi Mark,

Finally, the right answers!

I had gotten some hard-to-understand suggestions in this direction from
Crystal, but the settings would not change using code very similar to yours.
I had just been guessing that the reason it wasn't working was because of
integrated security, and your remarks confirm that.

Now the last difficult part - how do I change from integrated security to a
login/pwd connection? Please let me know at your earliest convenience - and
thanks so much!

Bernie

Bernie,

I have gone through this, and the following code circumvents all of the

known bugs that I worked through to resolve the problem. Apparently there
are more obvious ways to handle this that simply don't work (or didn't when
I wrote the code).

I store connection information in a 'Registration' dll file that is

located on each client. That way I can have an identical application
running on many different clients, and each uses it's own set of connection
info to get to the appropriate server and database. You could also use
application settings that the users can change themselves.

With this in place, I can create or revise reports on my dev machine and

simply copy the report file to any and all clients with no changes at all,
which was the main goal. The clients do not need Crystal Reports, and you
certainly don't have to build the reports for each client.

One note: this particular method will not work if you use Windows

Integrated Security to connect the report to the database on your dev
machine. So, if you used Integrated Security, and you want to use this
code, open each report, change the database connection to use a UserName &
Password, and re-save it. I informed Crystal that it would be really nice
if this could be changed at run-time, but I am not aware if they have
accomplished this yet.

Declarations...
Imports CrystalDecisions.Shared
Imports CrystalDecisions.CrystalReports.Engine

...
'Pass connection info
Dim crTableLogonInfo As New TableLogOnInfo
Dim crConnectionInfo As New ConnectionInfo
Dim crTable As Table
Dim subRepDoc As New ReportDocument
Dim crSection As Section
Dim crReportObject As ReportObject
Dim crSubreportObject As SubreportObject
With crConnectionInfo
.DatabaseName = <<Insert DatabaseName>>
.ServerName = <<Insert ServerName or IP Address and Port>>
.UserID = <<Insert UserID>>
.Password = <<Insert Password>>
End With
crTableLogonInfo.ConnectionInfo = crConnectionInfo

'CurrentReport is the ReportDocument loaded from a file earlier in this subroutine
For Each crTable In CurrentReport.Database.Tables
crTable.ApplyLogOnInfo(crTableLogonInfo)
crTable.Location = crTable.Name
Next

'If you have any sub-reports, they need the connection info too...
For Each crSection In CurrentReport.ReportDefinition.Sections
For Each crReportObject In crSection.ReportObjects
If crReportObject.Kind =

ReportObjectKind.SubreportObject Then

 

[Bernie Yaeger]

Hi Mark,

Nevermind - figured that out.

Once again, thanks so much - major headache gone.

Bernie

Bernie,

I have gone through this, and the following code circumvents all of the

known bugs that I worked through to resolve the problem. Apparently there
are more obvious ways to handle this that simply don't work (or didn't when
I wrote the code).

I store connection information in a 'Registration' dll file that is

located on each client. That way I can have an identical application
running on many different clients, and each uses it's own set of connection
info to get to the appropriate server and database. You could also use
application settings that the users can change themselves.

With this in place, I can create or revise reports on my dev machine and

simply copy the report file to any and all clients with no changes at all,
which was the main goal. The clients do not need Crystal Reports, and you
certainly don't have to build the reports for each client.

One note: this particular method will not work if you use Windows

Integrated Security to connect the report to the database on your dev
machine. So, if you used Integrated Security, and you want to use this
code, open each report, change the database connection to use a UserName &
Password, and re-save it. I informed Crystal that it would be really nice
if this could be changed at run-time, but I am not aware if they have
accomplished this yet.

Declarations...
Imports CrystalDecisions.Shared
Imports CrystalDecisions.CrystalReports.Engine

...
'Pass connection info
Dim crTableLogonInfo As New TableLogOnInfo
Dim crConnectionInfo As New ConnectionInfo
Dim crTable As Table
Dim subRepDoc As New ReportDocument
Dim crSection As Section
Dim crReportObject As ReportObject
Dim crSubreportObject As SubreportObject
With crConnectionInfo
.DatabaseName = <<Insert DatabaseName>>
.ServerName = <<Insert ServerName or IP Address and Port>>
.UserID = <<Insert UserID>>
.Password = <<Insert Password>>
End With
crTableLogonInfo.ConnectionInfo = crConnectionInfo

'CurrentReport is the ReportDocument loaded from a file earlier in this subroutine
For Each crTable In CurrentReport.Database.Tables
crTable.ApplyLogOnInfo(crTableLogonInfo)
crTable.Location = crTable.Name
Next

'If you have any sub-reports, they need the connection info too...
For Each crSection In CurrentReport.ReportDefinition.Sections
For Each crReportObject In crSection.ReportObjects
If crReportObject.Kind =

ReportObjectKind.SubreportObject Then

 

[Guest]

Bernie

I'm sorry I didn't get back to you, I'm not in these newsgroups very often

I'm glad to hear that you got everything situated

Best Regards
Mark Lauser - Crimson Software