DSN & SQL Server Login methods

[tyreejp]

If a report is created while connected to a database using a DSN, is it possible to apply SQL Server Account login information at runtime in your vb program on a machine that has no DSN's defined?

 

[vidru]

What version of Crystal, development environment, and database type?

-dave

 

[tyreejp]

I'm using Visual Studio .NET 2003 (VB.NET) and I've tried a version 8 CR, version 11, and the integrated version (which I believe to be based on 8.x) of CR that comes with VS.NET 2003. All of them have the same results. If our reports department created the report using a DSN that exists on their machine, I get stuck in that "logon loop" in a VB.NET program. I pass the Connection Info to each table in the report using this method.

For i = 0 To MyReport.Database.Tables.Count - 1
logOnInfo.ConnectionInfo.ServerName = "xxxxxx"
logOnInfo.ConnectionInfo.DatabaseName = "xxxxx"
logOnInfo.ConnectionInfo.UserID = "xxxxx"
logOnInfo.ConnectionInfo.Password = "xxxxx"
MyReport.Database.Tables.Item(i).ApplyLogOnInfo(logOnInfo)
Next i

In my code, ServerName is NOT the DSN Name the report creator used... it's an actual SQL Server 2000 server.

The way our report department creates the reports is, they open the CR IDE, connect to our DB using a DSN on their machine, pull in the tables/fields they need and go from there.

In my VB.NET program, I'm trying to specify the actual server name, database name, userid and password and get the logon failed message.

If I create the report on my own, using the OLE DB driver for SQL Serverin place of the ODBC RDO driver, then my code works fine.

If it's not possible to design the report using the DSN (trusted connection) and then try and specify logon information at runtime, then that's fine, I can stop chasing my tail looking for a solution.

Any and all help is greatly appreciated.

James

 

[vidru]

I'm not sure that you can do it with .NET (you can with VB6 by deleting the ConnectionInfo, and changing the connectivity .dll, etc.). The two choices I see are:
1) Update all of the reports to use a native SQL Server connection, or
2) Leave them as they are, and create the DSN on each machine.

-dave