Any guidance about checking this Designer universe option please?. We have over 40 automatcally generated contexts and thus you can guess what the structure probably loooks like. Many chasms, and 3 contexts that resolve 3 structure loops.
I feel it may be safer to not set it but if this helps MPSL object selection for summary tabs then this is woth regarding i think? Regards,
Grayham
Listserv Archives (BOB member since 2002-06-25)
I have a question regarding the allow selction of multiple context. If you do not allow this so its unchecked. should it allow them to choose objects from different contexts or would it just create 2 sepearate queries and then create 2 seperate tables. I though it just wouldn’t allow them to choose objects from different contexts and give them some type of error when they try to run a query with objects form multiple contexts. But it let them run the query it just created seperate tables. Just wanted to find out if thats what its suspose to be doing. Thanks.
Stacy Woodring
Programmer/Analyst
Performance, Inc
919-933-9113 x389
Listserv Archives (BOB member since 2002-06-25)
In a message dated Mon, 20 Aug 2001 3:29:43 PM Eastern Daylight Time, “Woodring, Stacy” stacywoodring@PERFORMANCEINC.COM writes:
I have a question regarding the allow selction of multiple context. If you do not allow this so its unchecked. should it allow them to choose objects from different contexts or would it just create 2 sepearate queries and then create 2 seperate tables. I though it just wouldn’t allow them to choose objects from different contexts and give them some type of error when they try to run a query with objects form multiple contexts. But it let them run the query it just created seperate tables. Just wanted to find out if thats what its suspose to be doing. Thanks.
There are two check boxes, and they are not the same thing. One says “Multiple SQL Statements for each context” and it is checked by default. The other is “Allow selection of multiple contexts” and it is off by default.
The first choice allows the user to select objects from different contexts, and it creates two (or more) SQL files; one for each context selected. If you clear this checkbox, the user will NOT be able to select objects from more than one context. The will get the oh-so-user-friendly message of “Incompatible combination of objects” instead.
The second option is off because it’s just weird. 
It allows the user to select more than one context when prompted to do so. Here’s what I mean, using Island Resorts as an example.
Create a query with Resort and Customer as the only two objects. Run the query. Before it will run, you have to select either SALES or RESERVATIONS as a context. You cannot select both. Now open the universe and mark the checkbox for “Allow selection of multiple contexts.” Run the same query again, and you can use the CTRL key to select both the SALES and the RESERVATIONS context at the same time.
What do the query results mean? Absolutely nothing. That’s why that option is off by default.
If you want to prevent users from using objects across contexts, you should clear the “Multiple SQL…” instead.
Regards,
Dave Rathbun
Integra Solutions
www.islink.com
Listserv Archives (BOB member since 2002-06-25)
Sorry to say, but I disagree with Dave in the following:
the option “allow multiple contexts” does make sense. If a user queries for “customer” and “resort” (no other opbjects) it is not clear WHAT he wants to see:
customers who made a reservation in a resort (=context reservations) OR
customers who already stayed in a resort (=context sales, i.e. they were already billed for it)
Sometimes it may be of interest to see all customer/resort combinations where there was either a reservation or a sale (in this case check the option “no duplicates” as well in the query panel…)
Having the “allow multiple contexts” disabled you can get this information by a “union” query only. If you enable the option, the user can specify one or more of the possible contexts (=available “facts”), which means he gets the requested information from all of the contexts. This is the reason why the generated SQL will then be a UNION query: you see all customer/resort combinations from all “fact” tables: reservations AND sales in our example.
This is as well the reason why you should give meaningful names to your contexts…
Nevertheless I agree with Dave in that it should be off by default, because it can be very time consuming to explain to the end user what exactly is going on behind the scenes…
hope this helps
Walter
Vivnotgasse 48, A-1120 Wien, Austria
http://www.delphi.at
Listserv Archives (BOB member since 2002-06-25)
In a message dated 01-08-24 11:12:31 EDT, you write:
Sometimes it may be of interest to see all customer/resort combinations
where there was either a reservation or a sale (in this case check the option “no duplicates” as well in the query panel…)
Yes, but the data is meaningless.
The user ends up looking at a list of names and resorts, without any indication about who went where (sales) or is planning to go (reservations). The next question is invariably something about where did that row of data come from? So you are back to using a union query so you can retrieve additional objects in the query.
It gets worse if you are using summary tables, which generally create loops and therefore contexts. What does it mean to allow a user to select two (or more) contexts at completely different summary levels?
Remember that the context prompt is only displayed for an ambiguous query to begin with. Selecting two or more contexts does not remove, and in fact increases (in my opinion) that ambiguity. I can’t say that I have ever distributed a universe with this setting turned on. Walter did an excellent job of explaining what it does, but I will respectfully disagree as to its usefulness. I just may not have encountered a data model that would require this feature yet.
Regards, Dave Rathbun
Integra Solutions www.islink.com
Tech Tips: www.islink.com/bobjtech.htm
Got a FAQ idea? email BUSOBListFAQ@aol.com Conference Travel Ideas: http://www.MomentsOfLight.com/trips_ut_boconf.html
Listserv Archives (BOB member since 2002-06-25)
Dave,
you are right in that it’s not easy to understand for endusers nor to train them, and as you mentioned, they will proceed then to get more details from the universe, so we end up at “normal” queries. And me too, I always leave this option un-checked, as well (up to now. But now I will try very hard to find a situation where it is essential to have that feature :-))…
Walter
Vivnotgasse 48, A-1120 Wien, Austria
http://www.delphi.at
Listserv Archives (BOB member since 2002-06-25)