Report Builder - Entities list behaving poorly.

While attempting to create a new report, I came across what I feel is some
odd behavior. I select an item in the Entities list, then drag an item from
the newly populated Fields list to the report area. Once I drop the field
item, the Entities list changes scope showing only the Entity from which I
made a selection and any items within it. I can't get back up to the main
list unless I undo the operation.
Being relatively new to this domain, I considered that I might be expecting
behavior that I shouldn't be, however, when I checked the tutorial provided,
the instructions led me to believe I was right in being perplexed, thus this
post.
Anyone have info?
Thank you,
Scottits a normal behavior.
The model only present entities which can be used regarding what you
currently have in the report.
of your entities have no links between them, there are not available to the
user.
This insure that the user will not select unrelated entities and generates
bad queries. (like full outer join queries)
You have to create some roles between your entities to allow the user to go
from 1 entity to another.
"ScottT" <ScottT@.discussions.microsoft.com> wrote in message
news:14E3E2DB-B9CD-4D3D-9176-3B1FA5D7E4E0@.microsoft.com...
> While attempting to create a new report, I came across what I feel is some
> odd behavior. I select an item in the Entities list, then drag an item
> from
> the newly populated Fields list to the report area. Once I drop the field
> item, the Entities list changes scope showing only the Entity from which I
> made a selection and any items within it. I can't get back up to the main
> list unless I undo the operation.
> Being relatively new to this domain, I considered that I might be
> expecting
> behavior that I shouldn't be, however, when I checked the tutorial
> provided,
> the instructions led me to believe I was right in being perplexed, thus
> this
> post.
> Anyone have info?
> Thank you,
> Scott
>|||I'm not sure if I'd call it "normal".
From my initial investigations there has to actually be a foreign key on the
tables in SQL Server.
If this is the case and you can't have "logical" relationships between
entities, than this will make things very difficult for a lot of people.
It will make report builder unusable for databases with complex
relationships between entities and legacy systems.
You should be able to have no actual foreign keys if you don't want to
(however bad practice this is).
"Jéjé" wrote:
> its a normal behavior.
> The model only present entities which can be used regarding what you
> currently have in the report.
> of your entities have no links between them, there are not available to the
> user.
> This insure that the user will not select unrelated entities and generates
> bad queries. (like full outer join queries)
> You have to create some roles between your entities to allow the user to go
> from 1 entity to another.
> "ScottT" <ScottT@.discussions.microsoft.com> wrote in message
> news:14E3E2DB-B9CD-4D3D-9176-3B1FA5D7E4E0@.microsoft.com...
> >
> > While attempting to create a new report, I came across what I feel is some
> > odd behavior. I select an item in the Entities list, then drag an item
> > from
> > the newly populated Fields list to the report area. Once I drop the field
> > item, the Entities list changes scope showing only the Entity from which I
> > made a selection and any items within it. I can't get back up to the main
> > list unless I undo the operation.
> >
> > Being relatively new to this domain, I considered that I might be
> > expecting
> > behavior that I shouldn't be, however, when I checked the tutorial
> > provided,
> > the instructions led me to believe I was right in being perplexed, thus
> > this
> > post.
> >
> > Anyone have info?
> >
> > Thank you,
> > Scott
> >
>
>|||Reportbuilder is not designed for complex schemas!
the system doesnt support complex relationships and other business rules.
Reportbuilder is (more) designed to give access to a well formatted
database, I mean a database with a "beautyfull" schema (good and simple
relationship).
Also, Reportbuilder is designed to be very intuitive for the end user. so
when the user start to play with the customer name, reportbuilder will
display only customer's related information because the MUST go through
these known entities to continue his report.
A user can't select a customer name and a product name as is, the user MUST
select the customer name, then the sales then the product, because the
question is "what are the product sales to my customers?"
the job you have to do is to create this easy to use reportbuilder model in
front of your database to insure that an end user can use your database
without any SQL knowledge.
if your database is too complex, you have to work hard to generate a report
builder model.
"James" <James@.discussions.microsoft.com> wrote in message
news:16CD66FF-16CA-44F6-9E50-496026C88464@.microsoft.com...
> I'm not sure if I'd call it "normal".
> From my initial investigations there has to actually be a foreign key on
> the
> tables in SQL Server.
> If this is the case and you can't have "logical" relationships between
> entities, than this will make things very difficult for a lot of people.
> It will make report builder unusable for databases with complex
> relationships between entities and legacy systems.
> You should be able to have no actual foreign keys if you don't want to
> (however bad practice this is).
> "Jéjé" wrote:
>> its a normal behavior.
>> The model only present entities which can be used regarding what you
>> currently have in the report.
>> of your entities have no links between them, there are not available to
>> the
>> user.
>> This insure that the user will not select unrelated entities and
>> generates
>> bad queries. (like full outer join queries)
>> You have to create some roles between your entities to allow the user to
>> go
>> from 1 entity to another.
>> "ScottT" <ScottT@.discussions.microsoft.com> wrote in message
>> news:14E3E2DB-B9CD-4D3D-9176-3B1FA5D7E4E0@.microsoft.com...
>> >
>> > While attempting to create a new report, I came across what I feel is
>> > some
>> > odd behavior. I select an item in the Entities list, then drag an item
>> > from
>> > the newly populated Fields list to the report area. Once I drop the
>> > field
>> > item, the Entities list changes scope showing only the Entity from
>> > which I
>> > made a selection and any items within it. I can't get back up to the
>> > main
>> > list unless I undo the operation.
>> >
>> > Being relatively new to this domain, I considered that I might be
>> > expecting
>> > behavior that I shouldn't be, however, when I checked the tutorial
>> > provided,
>> > the instructions led me to believe I was right in being perplexed, thus
>> > this
>> > post.
>> >
>> > Anyone have info?
>> >
>> > Thank you,
>> > Scott
>> >
>>|||I agree with what you're saying about the reportbuilder being a simple tool
for users without much or any knowledge of SQL or the particular database.
The bit I don't understand is why we are so limited in what we can do when
building the model.
This is a layer of abstraction and so it shouldn't matter if the actual
database is complicated underneath as long as the final model you present the
user with is straight forward.
Whats the point of having the layer of abstraction if everything has to be
in the database, you might as well report directly from the database.
As far as you know, is there definitely no way to say 2 tables are related
in your model that don't have an actual foreign key in SQL Server?
"Jéjé" wrote:
> Reportbuilder is not designed for complex schemas!
> the system doesnt support complex relationships and other business rules.
> Reportbuilder is (more) designed to give access to a well formatted
> database, I mean a database with a "beautyfull" schema (good and simple
> relationship).
> Also, Reportbuilder is designed to be very intuitive for the end user. so
> when the user start to play with the customer name, reportbuilder will
> display only customer's related information because the MUST go through
> these known entities to continue his report.
> A user can't select a customer name and a product name as is, the user MUST
> select the customer name, then the sales then the product, because the
> question is "what are the product sales to my customers?"
> the job you have to do is to create this easy to use reportbuilder model in
> front of your database to insure that an end user can use your database
> without any SQL knowledge.
> if your database is too complex, you have to work hard to generate a report
> builder model.
>
> "James" <James@.discussions.microsoft.com> wrote in message
> news:16CD66FF-16CA-44F6-9E50-496026C88464@.microsoft.com...
> > I'm not sure if I'd call it "normal".
> > From my initial investigations there has to actually be a foreign key on
> > the
> > tables in SQL Server.
> > If this is the case and you can't have "logical" relationships between
> > entities, than this will make things very difficult for a lot of people.
> > It will make report builder unusable for databases with complex
> > relationships between entities and legacy systems.
> > You should be able to have no actual foreign keys if you don't want to
> > (however bad practice this is).
> >
> > "Jéjé" wrote:
> >
> >> its a normal behavior.
> >> The model only present entities which can be used regarding what you
> >> currently have in the report.
> >> of your entities have no links between them, there are not available to
> >> the
> >> user.
> >> This insure that the user will not select unrelated entities and
> >> generates
> >> bad queries. (like full outer join queries)
> >>
> >> You have to create some roles between your entities to allow the user to
> >> go
> >> from 1 entity to another.
> >>
> >> "ScottT" <ScottT@.discussions.microsoft.com> wrote in message
> >> news:14E3E2DB-B9CD-4D3D-9176-3B1FA5D7E4E0@.microsoft.com...
> >> >
> >> > While attempting to create a new report, I came across what I feel is
> >> > some
> >> > odd behavior. I select an item in the Entities list, then drag an item
> >> > from
> >> > the newly populated Fields list to the report area. Once I drop the
> >> > field
> >> > item, the Entities list changes scope showing only the Entity from
> >> > which I
> >> > made a selection and any items within it. I can't get back up to the
> >> > main
> >> > list unless I undo the operation.
> >> >
> >> > Being relatively new to this domain, I considered that I might be
> >> > expecting
> >> > behavior that I shouldn't be, however, when I checked the tutorial
> >> > provided,
> >> > the instructions led me to believe I was right in being perplexed, thus
> >> > this
> >> > post.
> >> >
> >> > Anyone have info?
> >> >
> >> > Thank you,
> >> > Scott
> >> >
> >>
> >>
> >>
>
>|||there is an abstraction layer, the DSV.
in the DSV you can create links that doesn't exists in the database, you can
add a layer of queries and other calculated columns etc...
So if there is no foreign key in the database, you can create a logical
relationship in the DSV.
you can use unrelated tables in the model.
but if there is no links, then the user can't use these 2 tables at the same
time in report builder.
"James" <James@.discussions.microsoft.com> wrote in message
news:6879B37B-A3DC-4871-B254-80BC0B93648D@.microsoft.com...
>I agree with what you're saying about the reportbuilder being a simple tool
> for users without much or any knowledge of SQL or the particular database.
> The bit I don't understand is why we are so limited in what we can do when
> building the model.
> This is a layer of abstraction and so it shouldn't matter if the actual
> database is complicated underneath as long as the final model you present
> the
> user with is straight forward.
> Whats the point of having the layer of abstraction if everything has to be
> in the database, you might as well report directly from the database.
> As far as you know, is there definitely no way to say 2 tables are related
> in your model that don't have an actual foreign key in SQL Server?
> "Jéjé" wrote:
>> Reportbuilder is not designed for complex schemas!
>> the system doesnt support complex relationships and other business rules.
>> Reportbuilder is (more) designed to give access to a well formatted
>> database, I mean a database with a "beautyfull" schema (good and simple
>> relationship).
>> Also, Reportbuilder is designed to be very intuitive for the end user. so
>> when the user start to play with the customer name, reportbuilder will
>> display only customer's related information because the MUST go through
>> these known entities to continue his report.
>> A user can't select a customer name and a product name as is, the user
>> MUST
>> select the customer name, then the sales then the product, because the
>> question is "what are the product sales to my customers?"
>> the job you have to do is to create this easy to use reportbuilder model
>> in
>> front of your database to insure that an end user can use your database
>> without any SQL knowledge.
>> if your database is too complex, you have to work hard to generate a
>> report
>> builder model.
>>
>> "James" <James@.discussions.microsoft.com> wrote in message
>> news:16CD66FF-16CA-44F6-9E50-496026C88464@.microsoft.com...
>> > I'm not sure if I'd call it "normal".
>> > From my initial investigations there has to actually be a foreign key
>> > on
>> > the
>> > tables in SQL Server.
>> > If this is the case and you can't have "logical" relationships between
>> > entities, than this will make things very difficult for a lot of
>> > people.
>> > It will make report builder unusable for databases with complex
>> > relationships between entities and legacy systems.
>> > You should be able to have no actual foreign keys if you don't want to
>> > (however bad practice this is).
>> >
>> > "Jéjé" wrote:
>> >
>> >> its a normal behavior.
>> >> The model only present entities which can be used regarding what you
>> >> currently have in the report.
>> >> of your entities have no links between them, there are not available
>> >> to
>> >> the
>> >> user.
>> >> This insure that the user will not select unrelated entities and
>> >> generates
>> >> bad queries. (like full outer join queries)
>> >>
>> >> You have to create some roles between your entities to allow the user
>> >> to
>> >> go
>> >> from 1 entity to another.
>> >>
>> >> "ScottT" <ScottT@.discussions.microsoft.com> wrote in message
>> >> news:14E3E2DB-B9CD-4D3D-9176-3B1FA5D7E4E0@.microsoft.com...
>> >> >
>> >> > While attempting to create a new report, I came across what I feel
>> >> > is
>> >> > some
>> >> > odd behavior. I select an item in the Entities list, then drag an
>> >> > item
>> >> > from
>> >> > the newly populated Fields list to the report area. Once I drop the
>> >> > field
>> >> > item, the Entities list changes scope showing only the Entity from
>> >> > which I
>> >> > made a selection and any items within it. I can't get back up to
>> >> > the
>> >> > main
>> >> > list unless I undo the operation.
>> >> >
>> >> > Being relatively new to this domain, I considered that I might be
>> >> > expecting
>> >> > behavior that I shouldn't be, however, when I checked the tutorial
>> >> > provided,
>> >> > the instructions led me to believe I was right in being perplexed,
>> >> > thus
>> >> > this
>> >> > post.
>> >> >
>> >> > Anyone have info?
>> >> >
>> >> > Thank you,
>> >> > Scott
>> >> >
>> >>
>> >>
>> >>
>>|||Thanks,
I was trying to do it through the designer view of the report model.
I didn't realise I wanted to be in the designer view of the Data Source View
instead.
"Jéjé" wrote:
> there is an abstraction layer, the DSV.
> in the DSV you can create links that doesn't exists in the database, you can
> add a layer of queries and other calculated columns etc...
> So if there is no foreign key in the database, you can create a logical
> relationship in the DSV.
> you can use unrelated tables in the model.
> but if there is no links, then the user can't use these 2 tables at the same
> time in report builder.
>
> "James" <James@.discussions.microsoft.com> wrote in message
> news:6879B37B-A3DC-4871-B254-80BC0B93648D@.microsoft.com...
> >I agree with what you're saying about the reportbuilder being a simple tool
> > for users without much or any knowledge of SQL or the particular database.
> >
> > The bit I don't understand is why we are so limited in what we can do when
> > building the model.
> > This is a layer of abstraction and so it shouldn't matter if the actual
> > database is complicated underneath as long as the final model you present
> > the
> > user with is straight forward.
> > Whats the point of having the layer of abstraction if everything has to be
> > in the database, you might as well report directly from the database.
> >
> > As far as you know, is there definitely no way to say 2 tables are related
> > in your model that don't have an actual foreign key in SQL Server?
> >
> > "Jéjé" wrote:
> >
> >> Reportbuilder is not designed for complex schemas!
> >> the system doesnt support complex relationships and other business rules.
> >>
> >> Reportbuilder is (more) designed to give access to a well formatted
> >> database, I mean a database with a "beautyfull" schema (good and simple
> >> relationship).
> >>
> >> Also, Reportbuilder is designed to be very intuitive for the end user. so
> >> when the user start to play with the customer name, reportbuilder will
> >> display only customer's related information because the MUST go through
> >> these known entities to continue his report.
> >> A user can't select a customer name and a product name as is, the user
> >> MUST
> >> select the customer name, then the sales then the product, because the
> >> question is "what are the product sales to my customers?"
> >>
> >> the job you have to do is to create this easy to use reportbuilder model
> >> in
> >> front of your database to insure that an end user can use your database
> >> without any SQL knowledge.
> >> if your database is too complex, you have to work hard to generate a
> >> report
> >> builder model.
> >>
> >>
> >> "James" <James@.discussions.microsoft.com> wrote in message
> >> news:16CD66FF-16CA-44F6-9E50-496026C88464@.microsoft.com...
> >> > I'm not sure if I'd call it "normal".
> >> > From my initial investigations there has to actually be a foreign key
> >> > on
> >> > the
> >> > tables in SQL Server.
> >> > If this is the case and you can't have "logical" relationships between
> >> > entities, than this will make things very difficult for a lot of
> >> > people.
> >> > It will make report builder unusable for databases with complex
> >> > relationships between entities and legacy systems.
> >> > You should be able to have no actual foreign keys if you don't want to
> >> > (however bad practice this is).
> >> >
> >> > "Jéjé" wrote:
> >> >
> >> >> its a normal behavior.
> >> >> The model only present entities which can be used regarding what you
> >> >> currently have in the report.
> >> >> of your entities have no links between them, there are not available
> >> >> to
> >> >> the
> >> >> user.
> >> >> This insure that the user will not select unrelated entities and
> >> >> generates
> >> >> bad queries. (like full outer join queries)
> >> >>
> >> >> You have to create some roles between your entities to allow the user
> >> >> to
> >> >> go
> >> >> from 1 entity to another.
> >> >>
> >> >> "ScottT" <ScottT@.discussions.microsoft.com> wrote in message
> >> >> news:14E3E2DB-B9CD-4D3D-9176-3B1FA5D7E4E0@.microsoft.com...
> >> >> >
> >> >> > While attempting to create a new report, I came across what I feel
> >> >> > is
> >> >> > some
> >> >> > odd behavior. I select an item in the Entities list, then drag an
> >> >> > item
> >> >> > from
> >> >> > the newly populated Fields list to the report area. Once I drop the
> >> >> > field
> >> >> > item, the Entities list changes scope showing only the Entity from
> >> >> > which I
> >> >> > made a selection and any items within it. I can't get back up to
> >> >> > the
> >> >> > main
> >> >> > list unless I undo the operation.
> >> >> >
> >> >> > Being relatively new to this domain, I considered that I might be
> >> >> > expecting
> >> >> > behavior that I shouldn't be, however, when I checked the tutorial
> >> >> > provided,
> >> >> > the instructions led me to believe I was right in being perplexed,
> >> >> > thus
> >> >> > this
> >> >> > post.
> >> >> >
> >> >> > Anyone have info?
> >> >> >
> >> >> > Thank you,
> >> >> > Scott
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>