Thursday, March 29, 2012

Error from AS2005 - Binding for column 'xxxxx' is not a ColumnBinding type

I've seen this question come up a couple times on the public .olap newsgroup, but I've never seen an answer, so I'm going to give it another try:

I'm getting an error when I try to incrementally process my SSAS 2005 cube:

Errors in the high-level relational engine. The binding for the 'column-name' column is not a ColumnBinding type.

In this case, the column name that's given is a name that occurs in only 1 table in the underlying schema, so I know unambiguously which column it's talking about. The relevant part of the schema is roughly this:

create table Date(
DateID int not null primary key,
/* ... */
);

create table File(
FileID int not null primary key,
FileDateID int not null foreign key references Date(DateID),
/* ... */
);

create table Fact(
/* ... */
DateID int not null foreign key references Date(DateID),
FileID int not null foreign key references File(FileID)
);

The column that's named in the error message is File.FileDateID. Note that this is not a pure snowflake schema - there's a "loop" that associates files with dates in addition to other date relationships within the main fact table. I'm just guessing that the root of the problem has something to do with non-snowflake-ness of the schema. Full processing of the database/cube works fine - it's only when I try to process incrementally or create aggregations that I get this error.

Can anyone explain what this error really means and what to do about it?Anyone?|||

Carl,

When you do the incremental processing, are you using a table as the source or a query?

Dave Fackler

|||

It was a query of the form select * from MyFactTable where SomeIncrementalCondition.

Of course, the error has gone away since I first started asking about this error a month ago. Something I changed since then "fixed" the problem (this is a product in development, so I'm constantly fiddling with the cube and dimension definitions - I have no idea which change fixed this problem, unfortunately).

No comments:

Post a Comment