Home

Products
       NCAA Tourney
       Loan Calculator
       Text / HTML Versioner
       HTML Fader
       HTML Scheduler
       SQL Reporting Services
       MySkype

Support & Forums
Thursday, February 09, 2012 You Are Here: Support & Forums  | 
Welcome to Module Masters support forums - the primary support mechanism for our products. Feel free to post your questions, and we will aim to respond in a timely manner.  We also encourage our users to post any feedback you may have.  You may also email us directly at service@modulemasters.com
Forums > Module Masters Forum > SQL Reporting Services
Subject: Dynamic parameters
Prev Next
You are not authorized to post a reply.

Author Messages
ecssdevUser is Offline

Posts:9
09/01/2008 17:04  

Hi

Maybe got this wrong, but as I have understood it:

PortalID and UserID are passed using session variables and as long as I have those fields in the target dataset an automatic lookup will apply.  I noted in one thread that for this to work the actual report dataset must be created by a parameterised stored procedure, could you confirm that please.

That the parameter value pairs in the modules settings form are static; that is I cannot set a parameter value in that form using a DNN custom attribute value on the user profile?  Please confirm that is the case.

If the last two situations are correct then I am right to deduce that for me to have a dataset on a report filtered to just show records 'allowed' to a particular user custom attribute I have to 'round trip' the data - that is import in the user records with the unique custom attribute values and then export out again to get the userID created on import and then match up the userID values using the custom attribute as a primary key on the dataset on which the report is based.

Sorry if a bit unclear but late here in the UK

hostUser is Offline

Posts:497
09/01/2008 23:47  
well, i am not entirely sure i understand the question, but you are right in that the userid or portalid must be a defined parameter within the report, however it does not necessarily have to correlate to a sproc....it could be a regular query for that matter.

it dos not have implicit capability to use any other profile variables, but this is an interesting idea we can research and possibly include in future releases if others would use it as well!
ecssdevUser is Offline

Posts:9
09/02/2008 03:50  
Here is an example; we have a finance package which creates the ClientAccountID internally. When we create an account in the portal for a new client this ClientAccountID is added to the new DNN account as an extended attribute on the user profile in the Name category. However, the DNN UserID is controlled by the portal and so it only has a value post account creation and as there are several ways for user accounts to be created we can't accurately predict the next UserID to be used.

We need to put the ClientAccountID (or another unique ID) as a parameter on the reports, so that clients only see their own records.

As I understand it we can't use the extended DNN property ClientAccountID (for the logged in user) as a parameter name value pair on the modules settings, say in the DN token form of [Profile:ClientAccountID] is this correct ?

If I can't use the extended property the only fix I can see is that right after DNN new user account creation we have to query the DNN database and extract the UserID for the added ClientAccountID and add it back as a value in a secondary index on the finance database and then we can parameterise the report by UserID and that client can be enabled on the portal. Until that round trip UserID process has completed the reports for that client will fail so it has to be controlled.

As you can see this is not very efficient and really goes against database normalisation rules.

So what we would like to do is to be able to pass the ClientAccountID securely into the report, not really a solution we would want to implement with 'hack' on the module. Any ideas ?
hostUser is Offline

Posts:497
09/02/2008 22:55  
Well, I think the "right" solution would be for us to enable profile parameters to be passed as session variables...but this won't happen as quick as you likely need it, so the short term fix is you could modify your sproc being used to go get the data to take the UserId and go fetch behind the scenes vi a subquery or something the clientaccountid and filter it implicitely....this could work, but again, probably not the best solution.
hostUser is Offline

Posts:497
09/12/2008 00:03  
We will be adding this feature in 4.1. We are about to release version 4.0 which upgrades the module to support SQL Reporting Services 2008. After this we will have a sub release to address profile parameters.
ecssdevUser is Offline

Posts:9
09/19/2008 03:52  

That sound great, will it support extended User profile attributes, that is custom ones added using the 'Add New Profile Property' link on the 'Manage Profile Properties' module?
hostUser is Offline

Posts:497
09/19/2008 07:09  
That is correct.
You are not authorized to post a reply.
Forums > Module Masters Forum > SQL Reporting Services > Dynamic parameters


ActiveForums 3.7
Copyright 2011 by Module Masters Privacy StatementTerms Of Use