Providing Database Login Credentials


Many reports you integrate using the RDC will be based on secure databases, requiring a user ID and password to be supplied before the report can retrieve data. In many cases, you will have already established a secure connection with the database through your application before report processing ever begins. In these cases, you ll probably want to pass these credentials directly to the report from within your code. This is particularly important to RDC developers, as the Report Viewer control included with the RDC will not prompt the user for login credentials if they have not been previously provided ”the viewer will simply throw an error when attempting to process the report. This is in contrast to other integration methods , such as CE Embedded Edition and Visual Studio .NET, which will automatically prompt users for login credentials if the code doesn t provide them.

Depending on how the report is designed, you may need to approach supplying the user ID and password to the report from several different perspectives. The simplest way to do this is to provide a single user ID and password to the entire report. Even if the report makes use of several database tables, you can supply a single user ID/password combination that will apply to all tables. If, however, you have created a report that mixes tables from separate databases, or you have included subreports in your main report, you may need to perform extra steps to provide login credentials to individual tables in the main report, or to the subreport.

To supply an all-encompassing user ID/password combination that will apply to all tables originating from the same database, navigate through the RDC object hierarchy to the Database object within the Report object. The LogOnServer method will log in to the database, providing a secure connection to all tables within that database. LogonServer syntax is

 LogOnServer <  databaseDLL  >  ,  <  Server  >  ,  <  Database  >  ,  <  UserID  >  ,  <  Password  > 

The following code fragment shows how to log in to a Microsoft SQL Server database via ODBC. The ODBC Data Source Name is Xtreme SQL Server, the database name is XTREME, the user ID is DBReader, and the password is DBPassword. No matter how many tables have been added to the report from this database (the main report only ”not subreports), this will satisfy login requirements for all of them.

 ' Login to entire database for main report 
Report.Database.LogOnServer "PDSODBC.DLL", _
"XTREME SQL Server", "XTREME", "DBReader", "DBPassword"

If you need to supply different sets of credentials to individual tables (or you just want a more robust way to retrieve and set database properties in general), version 10 of the RDC exposes Connection Information property bags. A property bag is a collection of properties that exist for a certain object. The number of members and names in the collection can change, however, depending on the type of object. In the case of Connection Information property bags, varying sets of properties exist within the DatabaseTable object s ConnectionProperties collection, depending on the particular database DLL being used for a particular table.

An alternative way, then, of supplying login credentials to an individual report table looks like this:

 ' Login to individual database tables 
Report.Database.Tables(1).ConnectionProperties("User ID") = "DBReader"
Report.Database.Tables(1).ConnectionProperties("Password") = "DBPassword"

In this example, two property bag properties from the ConnectionProperties collection (User ID and Password) are set for the first table in the database.

Logging In to Subreports

While the requirement to potentially provide different login credentials to individual tables in the main report is one consideration, logging in to subreports is another. Because subreports contain unique database connections separate from the main report, you will need to provide login credentials to each of them separate from the main report. The RDC object model deals with subreports in a fashion that requires a bit of extra coding.

Because a subreport is, in essence, a report within a report, it possesses its own unique set of properties, methods, and events. Therefore, in order to completely control it, a separate RDC Report object must be declared and assigned to each subreport. Then, that subreport s properties (such as the Database object ConnectionProperties collection) can be manipulated from within their own Report object.

Examine the following sample code:

 ' Login to database for subreport 
Dim Top5ProductsSub As CRAXDRT.Report
Set Top5ProductsSub = Report.Subreport1.OpenSubreport
Top5ProductsSub.Database.LogOnServer "PDSODBC.DLL", _
"XTREME SQL Server", "XTREME", "DBReader", "DBPassword"

In this example, an additional Report object is declared, using the fully qualified object type of CRAXDRT.Report. It is then set to the subreport by navigating to the subreport within the main report object. The subreport object s OpenSubreport method is executed, which creates another RDC Report object (named Top5ProductsSub) just for the subreport. Then, the Database object s LogOnServer method, or ConnectionProperties collection, can be used to supply login credentials.

Tip  

More information on working with subreports can be found later in this chapter, under RDC Subreports.




Crystal Reports 10
Crystal Reports 10: The Complete Reference
ISBN: B005DI80VA
EAN: N/A
Year: 2004
Pages: 223
Authors: George Peck

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net