To Whom It May Concern:

It would seem that the XML file that defines the DSV which is usually named
something to the effect of [PROJECT NAME].dsv does not house the XML that is
changed when the DSV is changed and resaved, as this file does not change
when you perform the preceeding action. So. Where is the most current XML
definition for the DSV stored, or is this non-changing [PROJECT NAME].dsv
XML file a bug?


Thanks in advance for your support!


Your Friendly Neighborhood DBA,
Paul

Are you saying following doesnt work :
1. Open project with BI Dev Studio.
2. Change DSV by adding/removing tables.
3. Save and exit.
4. Open the project again and you dont see the changes you've made?

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights



"Paul McKirdy" <paul.mckirdy (AT) compass (DOT) net> wrote

Hello Edward,

It seems to be a mix-mash. Generally we do see changes visually persist
through closing and reloading the project. However, the XML file still
contains even objects that don't exist anymore in the visual DSV, and in
some cases we do actually see changes not persist visually as well. I was
thinking that if the DSV has an alternate XML file that is 100% definitely
used to outline the DSV we could correct
those XML definitions. It just seems like when we make changes in VS to the
DSV, those changes are not properly updating the *.DSV XML file, so I am
thinking that maybe there is another XML file that we should be looking at?

I apologize for the ambiguity, we are still trying to narrow down exact
reproductions of the difficulty. One definite one is that old objects that
have been deleted still persist in the *.DSV XML file.

Thanks!
Paul

"Edward Melomed [MSFT]" <edwardm (AT) norely (DOT) micrsoft.com> wrote

This is especially noticable when deploying an SSAS 2005 project to a
different server and swapping out the data source to point to a larger
version of the Data Warehouse that does not contain foreign keys due to its
size.

Even though some fact tables and dimension tables were reset to point to the
new data source in this manner:

1. change original table to named query
2. change named query back to original table

in order to fix mismatched key error between fact and dim tables that did
not exist in reality and not lose connected objects, the xml code still
references fact tables and foreign keys that existed on the original database
but don't exist on the new one and are no longer referenced in the designer
version of the dsv.

The good thing is the cube seems to load off of the designer version of the
dsv and what is in the code version is irrelevant and not worth viewing.
However, would like to know of a way to refresh the dsv code so it matches
with the designer because the existing setup makes me reluctant to deploy it
to a production server.


"Paul McKirdy" wrote:

It is not clear, what do you mean when you are talking about "code version
of DSV" vs "designer version of DSV".
Do you mean the .dsv file saved as part of the project? What about "code"
version? Where is it that?

I would think it makes sense: In cases when you need to re-direct your DSV
to another version of the relational database, you need to update all the
objects in DSV that are different.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights


"bhorwatt" <bhorwatt (AT) discussions (DOT) microsoft.com> wrote

When you right click on the data source view in the project solution, it
gives you the options View Code and View Designer. The XML displayed in View
Code does not match with the GUI in View Designer. Foreign keys and fact
table names referenced in the XML are no longer in the View Designer diagram.
I'm not sure how to get them back in sync.

"Edward Melomed [MSFT]" wrote: