Showing posts with label building. Show all posts
Showing posts with label building. Show all posts

Friday, March 30, 2012

Report Parameters

hello
i am building a report which is going to show me list of candidates from
different groups for that i have created a qurey that display group list. and
a qurey display orginal data (candidate list) my problem is i can only select
one group at time for report parameter from group list can i do multi select
from that report pls any one help me out
Adnan AwanOn Oct 4, 10:30 am, Adnan Awan <AdnanA...@.discussions.microsoft.com>
wrote:
> hello
> i am building a report which is going to show me list of candidates from
> different groups for that i have created a qurey that display group list. and
> a qurey display orginal data (candidate list) my problem is i can only select
> one group at time for report parameter from group list can i do multi select
> from that report pls any one help me out
> Adnan Awan
If I'm understanding you correctly, you can create a multi-select
parameter via the Report tab -> Report Parameters... Then in the
stored procedure/query that is sourcing the report, you can create a
while loop to split the multiselect items in the input stored
procedure parameter (normally delimited by commas). You could load a
temp table w/these values and then base your query on ...'where xxxxx
not in (select xxxxx from #SomeTempTable)', etc. Hope this helps.
Regards,
Enrique Martinez
Sr. Software Consultant

Friday, March 23, 2012

Report Models using Islookup and expandinline

I am building and deploying models.

I have many small description tables, they include two attributes. On attribute is the key (which is a code or type) and the other is a varchar description. They tables are each optionalone related to the primary table. I am "denormalizing" the description tables using Islookup. I change the Role in the primary table to ISLOOKUP, I modify the defaultattributes to remove the code or type key attribute, only the description attribute is now a detailattribute. I hide the key attribute just in case.

In most cases when I do this the description tables are denormalized and the user now sees only the description in the primary table in report builder. But in a few cases the key attribute (which is normally a code - 1, 2, 4, 5, etc) is displayed, it displays even though it is Hidden, ISlookup is defined and I remove it from the default attributes.

I don't know why some work and some don't, the relationships seem to be identical in my view. Is there something in the model that could designate a table can be used as a ISLookup?

To attempt to work around this I have tried using expandinline.

Any ideas?

Report Builder "honors" the Entity.IsLookup property in the UI if and only if the cardinality of the role used to reach the entity is One/OptionalOne, and the lookup entity has exactly one attribute in its IdentifyingAttributes collection.

|||the entity lookup property is one/optional one and there is only one identifying attribute, this is exactly the issue I have, it does not seem to be consistent. And I cannot find any other differences in the tables to help me understand why this is happening.|||There is one other minor constraint - the one identifying attribute must actually belong to the lookup entity (it cannot come from a related entity). Is this the problem?|||No, it does not come from a related table. I used expandinline and it looks good, if I only have the one identifying attribute I seem to get the correct result, anything I should be aware of?|||

If you use ExpandInline, the user will not be able to navigate to the lookup entity using the Advanced Explorer mode in Report Builder. This is useful when creating reports that compare an item to other items with the same lookup value.

It also sounds like you may have confused the DefaultDetailAttributes and IdentifyingAttributes collections on the lookup entity. For an entity to be treated as a lookup, the IdentifyingAttributes collection must have exactly one attribute in it. The contents of DefaultDetailAttributes is irrelevant.

Report Models using Islookup and expandinline

I am building and deploying models.

I have many small description tables, they include two attributes. On attribute is the key (which is a code or type) and the other is a varchar description. They tables are each optionalone related to the primary table. I am "denormalizing" the description tables using Islookup. I change the Role in the primary table to ISLOOKUP, I modify the defaultattributes to remove the code or type key attribute, only the description attribute is now a detailattribute. I hide the key attribute just in case.

In most cases when I do this the description tables are denormalized and the user now sees only the description in the primary table in report builder. But in a few cases the key attribute (which is normally a code - 1, 2, 4, 5, etc) is displayed, it displays even though it is Hidden, ISlookup is defined and I remove it from the default attributes.

I don't know why some work and some don't, the relationships seem to be identical in my view. Is there something in the model that could designate a table can be used as a ISLookup?

To attempt to work around this I have tried using expandinline.

Any ideas?

Report Builder "honors" the Entity.IsLookup property in the UI if and only if the cardinality of the role used to reach the entity is One/OptionalOne, and the lookup entity has exactly one attribute in its IdentifyingAttributes collection.

|||the entity lookup property is one/optional one and there is only one identifying attribute, this is exactly the issue I have, it does not seem to be consistent. And I cannot find any other differences in the tables to help me understand why this is happening.|||There is one other minor constraint - the one identifying attribute must actually belong to the lookup entity (it cannot come from a related entity). Is this the problem?|||No, it does not come from a related table. I used expandinline and it looks good, if I only have the one identifying attribute I seem to get the correct result, anything I should be aware of?|||

If you use ExpandInline, the user will not be able to navigate to the lookup entity using the Advanced Explorer mode in Report Builder. This is useful when creating reports that compare an item to other items with the same lookup value.

It also sounds like you may have confused the DefaultDetailAttributes and IdentifyingAttributes collections on the lookup entity. For an entity to be treated as a lookup, the IdentifyingAttributes collection must have exactly one attribute in it. The contents of DefaultDetailAttributes is irrelevant.

Report Model Timeout

When building a report model on a large set of data I constantly get a
timeouts before it complets building. I've changed the query timeout on the
data source to both 600 seconds (the max) and 0 seconds (which should be no
timeout) and I still get timeouts. I installed SP1 for SQL Server 2005
because it talked about something similiar to this issue but it didn't fix
this issue. I still get a timeout and the model is not built. Is there
anything else I can try and is this expected behavior?
Thanks.No one has timeouts when building models against large tables'
"Aaron" wrote:
> When building a report model on a large set of data I constantly get a
> timeouts before it complets building. I've changed the query timeout on the
> data source to both 600 seconds (the max) and 0 seconds (which should be no
> timeout) and I still get timeouts. I installed SP1 for SQL Server 2005
> because it talked about something similiar to this issue but it didn't fix
> this issue. I still get a timeout and the model is not built. Is there
> anything else I can try and is this expected behavior?
> Thanks.|||you need to give it more than 13 minutes, buddy
when you say.. large tables; you're talking about a few, maybe a dozen
tables; with like a million records?
give us some scope; ok?
-Aaron
Aaron wrote:
> No one has timeouts when building models against large tables'
> "Aaron" wrote:
> > When building a report model on a large set of data I constantly get a
> > timeouts before it complets building. I've changed the query timeout on the
> > data source to both 600 seconds (the max) and 0 seconds (which should be no
> > timeout) and I still get timeouts. I installed SP1 for SQL Server 2005
> > because it talked about something similiar to this issue but it didn't fix
> > this issue. I still get a timeout and the model is not built. Is there
> > anything else I can try and is this expected behavior?
> >
> > Thanks.sql