Fail to run report made with report builder

Hi,

I am completely new to Report Builder. I created and deployed a report model and opened the Report Builder, and created a very simple report by dragging a table into the report. When running the report i get this error:

Keyword not supported: 'provider'.
-
Cannot create a connection to data source 'dataSource1'.
-
An error has occurred during report processing.
The data source name that I used in the report model was not called dataSource1.

Approximately the same error is displayed if I deploy (save) the report to the report server:

An error has occurred during report processing.
Cannot create a connection to data source 'dataSource1'.
Keyword not supported: 'provider'.
The report server itself seems to work fine, because I can deploy reports that are created the old way (ie from within BI Development Studio)

I am using the September CTP.

BR
KaDid you create model using Model Designer?

Fact Table Optimal Design

I have a working model, but looking to optimize it. Particulary the fact table. Here is how fact table looks:

ProductKey ChargeAKey ChargeBKey ChargeCKey ChargeA$ ChargeB$ ChargeC$ TotalABC$

1 1 0 0 2$ 0 0 2$

1 2 0 0 3$ 0 0 3$

1 0 1 0 0 4$ 0 4$

1 0 0 1 0 0 2$ 2$

1 0 0 2 0 0 3$ 3$

1 0 0 3 0 0 3$ 3$

... now some explanation.. granuality of fact table is Product + ChargeType. each charge type (A, B, C) has it's own dimension table with its own unique list of attributes and they all come from different sources. The simplest loading would append each Product + ChargeX to the table. I was thinking of option b - settingup fact table as Product + ChargeType + ChargeKey + Chargeamount, but this design in my opinion is less friendly then the original because user would have to know what charges have to be filtered down first by type to get to specific key and its attributes... what I don't like about option a is that it takes a lot of space and there are fields populated with only meningless 0 vs having everything compressed into few records. e.g. above exmple could be designed to have only 3 records vs. 6 which translates in huge savings when we are talking millions of records.Would anyone have anyexperience with similiar challenge? I would be able to solve this with complex ETL procedures, but there has to be something much simplier. I am still not sure if this is design or ETL solution... any feedback greatly appreciated.

My general recommendation on dimensional design is to stay focused on your business users. What is the business process, activity, or event this table represents? How would your users describe the facts associated with this process/activity/event?

It appears you have incorporated a dimension (charge type) with three values into your model. If each charge type represents a different event/process/activity, then three fact tables are in order. If this is a single event that could be broken down by charge type (of which there are currently three identified), then a single fact table is required with a charge type dimension. (What happens if a fourth charge type is introduced?)

B.

|||

Thank You. That's right I always keep end user in mind because it is for him that data is being presented... and you always think the performance and simplicity. You gave me the answer: "What happens if a fourth charge type is intorduced?".. I will be in a lot of work, if not trouble, to integrate everything into one fact table.. Thanks.

Fact table design

I am creating the data model for an insurance related datawarehouse, I have 3 types of Claims that we want to report on:
health, dental and drug. Some of the data the user needs will be in all 3 but others will be in only one or two of the fact tables.
My question is should these 3 types of claims be divided into 3 fact tables or should I combine them leaving the fields that only apply to one of the types null.
Thanks in advance for the help
If I understand correctly you basically are talking about which users can have access to view which type of claims. Is this correct?
If this is your question then I think you can solve via using roles and permissions on the cube. I myself am in the learning process - as my name implies ;), but based on my so far understanding, this should do the trick.
Please let me know if this solves your problem? Kindly post your reply to the newsgroup.
By copy of this mail to the experts, I would like to ask a related question: Is it a good or bad design practice to have multiple fact tables?
************************************************** ********************
Sent via Fuzzy Software @. http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...
|||Actually what I am looking for is more of a best practice, is it better to have one fact table that has columns that are null or have multiple fact tables.
|||If you include all measures related to all three types of claims, then your fact table can get huge depending on how much claims activity you process, amount of history, and record width.
If you put them in different fact tables, you can still join them by your degenerate key(primary key -ex. claims number), but at least you won't be wasting space.
-- shache wrote: --
I am creating the data model for an insurance related datawarehouse, I have 3 types of Claims that we want to report on:
health, dental and drug. Some of the data the user needs will be in all 3 but others will be in only one or two of the fact tables.
My question is should these 3 types of claims be divided into 3 fact tables or should I combine them leaving the fields that only apply to one of the types null.
Thanks in advance for the help
|||Hi,
A silly question from me:
Please explain what you mean by "(primary key -ex. claims number)"...the
reason for asking is that I'm new to this... is this the same thing as a
"surrogate key" (another term that I read in an article.
Regards.

> If you include all measures related to all three types of claims, then
> your fact table can get huge depending on how much claims activity you
> process, amount of history, and record width.
> If you put them in different fact tables, you can still join them by
> your degenerate key(primary key -ex. claims number), but at least you
> won't be wasting space.
|||in the fact table, there is no primary key because you have "degenerated' the primary key from the source system. It has ceased to become the primary key in the fact table even though the field still exists. So, in general, a claim number was the primary
key in your claims source system, but now it is just an ordinary field.
In the dimension table, the primary key is no longer valid anymore because a surrogate key is created. The surrogate key is a meangless number. So a customerid was a primary key in your claims system, but now it is not a PK anymore in your dimension table
. You have just a number(surrogate key) to describe your product and that is your new PK.
I'll understand if it is still confusing.
primary key is not the same as surrogate key. primary key is the same as what is called the degenerate key in the fact table. The surrogate key is actually the primary key in the dimension table.
-- Learner wrote: --
Hi,
A silly question from me:
Please explain what you mean by "(primary key -ex. claims number)"...the
reason for asking is that I'm new to this... is this the same thing as a
"surrogate key" (another term that I read in an article.
Regards.

> If you include all measures related to all three types of claims, then
> your fact table can get huge depending on how much claims activity you
> process, amount of history, and record width.
> If you put them in different fact tables, you can still join them by
> your degenerate key(primary key -ex. claims number), but at least you
> won't be wasting space.

Fact table design

I am creating the data model for an insurance related datawarehouse, I have
3 types of Claims that we want to report on:
health, dental and drug. Some of the data the user needs will be in all 3 b
ut others will be in only one or two of the fact tables.
My question is should these 3 types of claims be divided into 3 fact tables
or should I combine them leaving the fields that only apply to one of the ty
pes null.
Thanks in advance for the helpIf I understand correctly you basically are talking about which users can ha
ve access to view which type of claims. Is this correct?
If this is your question then I think you can solve via using roles and perm
issions on the cube. I myself am in the learning process - as my name implie
s ;), but based on my so far understanding, this should do the trick.
Please let me know if this solves your problem? Kindly post your reply to th
e newsgroup.
By copy of this mail to the experts, I would like to ask a related question:
Is it a good or bad design practice to have multiple fact tables?
****************************************
******************************
Sent via Fuzzy Software @. http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET
resources...|||Actually what I am looking for is more of a best practice, is it better to h
ave one fact table that has columns that are null or have multiple fact tabl
es.|||If you include all measures related to all three types of claims, then your
fact table can get huge depending on how much claims activity you process, a
mount of history, and record width.
If you put them in different fact tables, you can still join them by your de
generate key(primary key -ex. claims number), but at least you won't be wast
ing space.
-- shache wrote: --
I am creating the data model for an insurance related datawarehouse, I have
3 types of Claims that we want to report on:
health, dental and drug. Some of the data the user needs will be in all 3 b
ut others will be in only one or two of the fact tables.
My question is should these 3 types of claims be divided into 3 fact tables
or should I combine them leaving the fields that only apply to one of the ty
pes null.
Thanks in advance for the help|||Hi,
A silly question from me:
Please explain what you mean by "(primary key -ex. claims number)"...the
reason for asking is that I'm new to this... is this the same thing as a
"surrogate key" (another term that I read in an article.
Regards.

> If you include all measures related to all three types of claims, then
> your fact table can get huge depending on how much claims activity you
> process, amount of history, and record width.
> If you put them in different fact tables, you can still join them by
> your degenerate key(primary key -ex. claims number), but at least you
> won't be wasting space.|||in the fact table, there is no primary key because you have "degenerated' th
e primary key from the source system. It has ceased to become the primary ke
y in the fact table even though the field still exists. So, in general, a cl
aim number was the primary
key in your claims source system, but now it is just an ordinary field.
In the dimension table, the primary key is no longer valid anymore because a
surrogate key is created. The surrogate key is a meangless number. So a cus
tomerid was a primary key in your claims system, but now it is not a PK anym
ore in your dimension table
. You have just a number(surrogate key) to describe your product and that is
your new PK.
I'll understand if it is still confusing.
primary key is not the same as surrogate key. primary key is the same as wha
t is called the degenerate key in the fact table. The surrogate key is actua
lly the primary key in the dimension table.
-- Learner wrote: --
Hi,
A silly question from me:
Please explain what you mean by "(primary key -ex. claims number)"...the
reason for asking is that I'm new to this... is this the same thing as a
"surrogate key" (another term that I read in an article.
Regards.

> If you include all measures related to all three types of claims, then
> your fact table can get huge depending on how much claims activity you
> process, amount of history, and record width.
> If you put them in different fact tables, you can still join them by
> your degenerate key(primary key -ex. claims number), but at least you
> won't be wasting space.|||There are a number of different characteristics between medical, dental and
RX drugs that facilitate analysis meaningful for management, diagnosis and p
rocedure codes having the largest variation. I would treat all three as sepa
rate facts and use views an
d virtual cubes for those situations where combining the three makes sense.