• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 248
  • Last Modified:

SQL Server Migration

Hi All

Any ideas here. I am doing a server migration as the organisation that I am contracted to has changed the service provider of their infrastructure and the two servers that I run my services through are on the old domain.

As such I have set up a 'stepping stone' virtual server on the new domain to provide un interrupted service whilst I move my two servers over to the new domain.

On this stepping stone server the only difference is that my two physical servers have enterprise SQL 2008R2 (database server) and standard SQL 2008R2 (cube database and web server), whereas the stepping stone server that has both the databases and cube databases and web service is running standard SQL 2008R2.
The only reason for having enterprise on the data server is for memory allocation. I have not used any of the additional enterprise features (so indexed views etc).

However one of the measures on my cube database gives me a -1 #IND error but only for one of the fiscal years. This fiscal year of data is the latest and is added in a union as it is temporarily coming from a different source and so I dumped it into different staging, release tables and unioned the data into the cube fact table in the data source view. The reason for this is that it has a different structure but is only a temporary source. The original source of data is expected to return shortly and will replace the temporary source period, so I will be removing the union statement from the data source view.

This all works perfectly on the original set up. I cant understand why its giving me this error on the new server.

Any ideas would be greatly appreciated.

Same service packs and everything.
0
trawley
Asked:
trawley
  • 3
1 Solution
 
trawleyAuthor Commented:
Think I might have found the problem.
0
 
Vijaya Reddy Pinnapa ReddyCommented:
Please mark your question as answered
0
 
trawleyAuthor Commented:
I havent exactly found the answer to this problem but I have solved it. The problem lay in the fact that I was performing a standardised rate with confidence intervals in the cube database. It was the confidence intervals that were producing the -1 #IND error for this period. Tracking back through all of the dependent calculations to the source of the data, it turns out that the new data stream lumps all of the over 85 age group into one category rather than divulging numbers for the quinary age bands over the age of 85. As such there are a number of fields containing nulls so by using isnull(quinaryageband, 0) I was able to solve the problem of the whole age group coming out as null.
However why this didnt manifest itself on the old server I will never know. It's a good lesson in never taking anything for granted.
I was assuming that because it gave expected results on the old server there was nothing wrong with the transact SQL in the views stored procs and functions etc that feed the cubes. To me this had to be something to do with the old and new server set up (and in fact there has to be some logical explanation along those lines to explain why it worked on one and not the other). However there was a deeper underlying problem which didnt intially occur to me.
Anyway sorted now so thanks very much anyone who took a look.
0
 
trawleyAuthor Commented:
Reasons for accepting my solution are contained in the solution itself. Grading myself a 'B' because I still do not understand the reason why I didnt get the -1#IND error on the old server set up in the first place.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now