Crystal Report parameter dialog box...please help!

Hi,
This is what i am doing:-

ReportDocument rdReport = new ReportDocument();

rdReport.Load("ReportLocation"); //ReportLocation is the file path.

rdReport.SetDataSource(dtsReportData); //dtsReportData is a DataSet that is populated at runtime.

crv.ReportSource = rdReport; //crv is a CrystalReportViewer on the win form.

I developed my app in VS 2003 and it was all running very smoothly. I recently migrated it to VS2005 and then I started getting this problem.
Although I dont think this is a VS 2005 issue; but something with CR
itself.

I'll try to explain my problem in detail.

I am using Crystal Reports XI; VS 2005; SQL Server 2000;

For all my reports, the reports' datasource is a Stored Procedure. And
in most cases than not, these are paramaterised SP's.

In my application, I have a listbox with a list of available reports.
The user then selects to view one report. This then loads up a
dynamically generated form with a tabpage for each of the parameters
that the Stored Procedure needs. The user then enters values for each
of the parameters. I then create a SQL statement( something like
...execute MyStoredProc value1 value2) where value1 etc are the values
the user entered for the parameters on the dynamyically generated form.
The resultant recordset is then stored into a DataSet object.

I then load the report into a ReportDocument object ie
rdReport.Load("ReportLocation"); assign the DataSet as the
ReportDocuments' Datasource ie rdReport.SetDataSource(dtsReportData);
and finally assign the ReportDocument to the CrystalReportViewer.

As i mentioned earlier, this was all working smoothly untill now...I am
getting the default CR "Enter Parameters" dialog and I havent got a
clue as to what has triggered this behaviour.

It is not possible for me to know how many parameters a stored
procedure for a report will contain and what those parameters will be
for reports designed in the future for the client.

I am pretty new to the world of reporting so excuse my
explanation...if you need any further information to understand my
problem, please let me know. I will really appreciate any help that you
can provide.

Thanks,
Mounil.You need to supply the parameters in front end application and set EnablePopup menu property to false

Cross DB dialog security issues. Was: Can't Route to another LOCAL Broker Instance

Hi Remus,

I am experiencing the same problem, and I can't get the easy fix to work. I drop and create the DB's in between tests, so it is not related to having an old certificate in the DB, as in the case of Tilfried.

The situation is as follows:

DB1 owned by login1, has a user for login2; this DB is for the initiator

DB2 owned by login2, has a user for login1; this DB hosts the target

Both DB's have TRUSTWORTHY flag set to ON

Error in sys.transmission_queue: 'Error 916, State 3: The server principal "Login1" is not able to access the database "DB2" under the current security context.

Going on a limp, I decide to add a remote service binding in DB1, binding the user for Login2 to the target service, even though BOL explicitly states that this is only required for cross-server communications. This does change the situation - I still get an error, but a new message is sys.transmission_queue: "Dialog security is unavailable for this covnersation because there is no certificate bound to the database principal (Id: 5). Either create a certificate for the principal, or specify ENCRYPTION = OFF when beginning the conversation." I already know that the first option works, but I wanted to get the simple solution running. As for the second option, I doublechecked and the initiating procedure DOES already specify ENCRYPTION = OFF in the BEGIN DIALOG CONVERSATION command. My theory is that the remote service binding somehow forces SB to use encryption, but (a) that is not stated in the error message, and (b) if so, then how to get the messages sent over to the target service without using the binding?

==> EDIT: Just saw that you confirmed this theory in your last reply to Tlifried. So I am indeed back to having to find out how to get this to work without remote service binding - it should be possible, but how?

BTW, SELECT @.@.VERSION shows that I'm on build 3054, in case it matters.

Between all the errors in BOL and less than helpfull error messages produced by SB, I feel like I'm slowly losing my sanity. Please help!

Best regards,

Hugo Kornelis

Hi Remus (or whoever is listening),

Just to make sure that I'm not looking in the wrong corner, I decided to make sure that the absence of certificates is the ONLY reason that the services won't talk to each other. So I made certificates for the dbo owner in each of the DBs, dumped them to file and used those files to create certificates for the corresponding users in the other DBs.

After setting up certificates like that, I still got the same error (Error 916, State 3) - but once I added a remote service binding, my dialog ran without further problems.

I still don't understand why a remote service binding is required even though BOL says (quote from the CREATE REMOTE SERVICE BINDING page): "A remote service binding is only necessary for initiating services that communicate with target services outside of the SQL Server instance." - but at least I am now certain that my problems with the version without certificates and with the trustworthy option set on are not related to any other errors in my setup.

Best, Hugo

|||

On the interaction between ENCRYPTION = ON/OFF and the presence/absence of a remote service binding see http://blogs.msdn.com/remusrusanu/archive/2006/07/07/659319.aspx. When a RSB is present, the login mapping between databases is discarded in favour of certificates. This is intentional, as a way to circumvent the problem of no wanting to enable TRUSTWORTHY bit (with all the instance level implications).

To map users trough logins, having TRUSTWORTHY ON is a required condition, but not suficcient. The complete story is detailed at http://msdn2.microsoft.com/en-us/library/ms188304.aspx. What you need is for DB2 to grant AUTHENTICATE permision to login1. TRUSTWORTHY bit is required only on DB1. This is nothing specific to Service Broker, using EXECUTE AS user = 'foo' in DB1 and then issue a USE DB2 statement would run into the same error.

I understand the errors are somehow cryptic and misterious, now the cat is out of the bag we hope to get better at next iteration. Tools would shorley help, give a shot to www.codeplex.com/slm

|||

Hugo Kornelis wrote:

I still don't understand why a remote service binding is required even though BOL says (quote from the CREATE REMOTE SERVICE BINDING page): "A remote service binding is only necessary for initiating services that communicate with target services outside of the SQL Server instance."

Remote service bindings are required for remote dialog security. However, altough not required, if present, they are honored for local dialogs.

|||

without reading the whole thread in detail, I found that the SQL Profiler lets you find problems within minutes, for which you would normally take hours or days of checking everything!

Trace shows messages and errors, you will never receive through SSB directly!