I'm having a problem processing cubes built with the
SQL Server Accelerator for Business Intelligence (SSABI)
product. The (unmodified) SSABI workbook constructs the
cubes (RA and SMA)
without an error but when I try to process them from either
Analysis Manager or msbiso_update.bat it gives the error:

Analysis Server Error: Internal error [Object does not
exist] '02/01/1900'

I am able to build many other cubes on the same system
without
a problem but none of them are as complex as the default
SSABI cubes.

I'm running Windows 2000 with SQL Server 2000 and have
applied SP3 for
both SQL Server and Analysis Services, I have applied the
OLAPQFE808
patch as required in the SSABI release notes. I've tried
the workaround
described in knowledgebase article 821103 (Bug #14037):

http://support.microsoft.com/default.aspx?kbid=821103

in the hope that it was a related problem but it had no
effect.

I suspect the problem is related to the processing of the
auto generated
time.standard shared dimensions in which the row
representing the
date 02/01/1900 contains a custom member formula for
the 'Current'
dimension member. I did wonder if it might be related to a
dd/mm/yyy
or mm/dd/yyyy date part ordering representation or locale
issue.

I was wondering if anyone else had had a similar
experience and are
there any (or many) other people in the UK using SSABI
without such
a problem.

One observation:
If I delete the week.standard dimension and the dependent
custom sets my problem goes away.

Unfortunately, I don't think its easy to persuade
the SSABI worksheep to not create the dimension;
its everything or nothing with the autogenerated time
dimension.

Hi John,

I have seen this one it's a localisation issue, I see these more as a Dutch
Analysis engineer :-)

You propably have your machine installed as English(United Kingdom), The
date format is: dd/mm/yyyy. If you change the data format into mm/dd/yyyy
English (US), edit the slicing of the partition and reprocessing partition
completes propably successfully

Another way to fix this for example is by using convert function (if the
source data is stored at SQL Server) to convert the member key column into
varchar, example:

Convert(varchar(12), ‘<Member key column expression>’, 101)
Note: 103 means mm/dd/yyyy format, 101 means dd/mm/yyyy format

- modify the time.standard dimension by changing the member key column for
levels
year, quarter and month as:
convert(varchar(12),"Dim_Time_Std_Year"."Year_Idx" ,101)
convert(varchar(12),"Dim_Time_Std_Qtr"."Qtr_Idx",1 01)
convert(varchar(12),"Dim_Time_Std_Mon"."Mon_Idx",1 01)

- Edit the partition of the cube to use the member of the time dimension.
The slicing value under the “Meta Data” pane of the Analysis Manager will
change to “dd/mm/yyyy” format.
- re-processing the partition

Let me know if it works out for you.
HTH,
Bas

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

Thanks Bas,

I tried the second suggestion - modifying the
time.standard dimension member key column expression
for the year , quarter and month levels and it didn't
appear to make a difference. I still got the same
"object does not exist" error when processing the cube.
Should I have done more? I didn't edit the cube
partition because I'm not using a (multi)partitioned
cube.

Its frustrating that bits of the source code for the
SSABI application are encrypted or password protected
so it is not possible to make changes to cope with
this locale issue. But is this an SSABI problem
or is it an Analysis Services error? I'm not sure
I really understand what is giving rise to the problem.
At what point do you think that a component is getting
confused over date part ordering?

At the moment the only way I have of processing the
cube is to delete the week.standard dimension and
its dependent custom sets. If I do that I end up with
a cube that appears to work but would you expect its
custom member formula to work ok?

John Bates

Hi John,

The time dimension has a member key column has the dbdate format. This
fails about the UK date format.

The convert function should fix this however I didn't test this myself, I
suggest you do some test yourself. I haven't SSABI under my fingers at the
moment. You could try using convert function (if the source data is stored
at SQL Server) to convert the member key column into varchar, exmple
Convert(varchar(12), ‘<Member key column expression>’, 103). I am not sure
anymore now if it shouldbe 101 or 103.

The data in AS should simply be stored in the US format that's all.

HTH,
Bas

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

Bas,

I have tried quite a lot of tests over the last few days
based around your suggestion of mapping the DBDate
values to varchar(12) using the technique that you describe
and it really doesn't seem to solve the problem. One of the
difficulties I run in to is that the virtual dimension week.standard
which is based on time.standard becomes invalid once you start
to play around with the type of the member key columns of time.standard.

If I delete the week.standard virtual dimension and its 7 dependent
sets ([Standard Previous Week], [Standard Last 2 Weeks] etc) I can
build the cube and it works fine. I notice that all the date values look
correct (both the dates that have been loaded from the sample data text
files and the rows in the time dimension for the year 1900 that have been
`pre-loaded' to represent the custom members).

I'm beginning to think that perhaps my problem is not a locale problem
but rather related to the problem described here:
http://support.microsoft.com/default.aspx?kbid=821103

Without the week.standard dimension everything is fine, all the dates
and custom members function as I would expect. I guess I'll have to
wait and see if the next Analysis Services service patch changes anything.

John Bates


""Bas Kersten [MSFT]"" <bask (AT) online (DOT) microsoft.com> wrote