I am fairly new to analysis services.When I process AdventureWorks dimension DimCustomer(facing the issue for other dimensions like DimEmployee too) saying for attribute Firstname has duplicate values. It is not a key attribute in my dimension. Can anyone please help me if i am missing something here ?
Thanks
Are there any trailing or leading spaces in the attribute or other special characters at the start or end? This can sometimes cause problems.
Also check you've got correctly defined attribute relationships between attributes.
Related
I am learning how to add the check constraint, but it did not really work as I expected.
So, I have a column limit, which actually require some constraints, as some of the user broke our system when they enter record back end.
Column 'limit':
Constraint expected : If not NULL or Empty, then record must be float/numeric.
Can anyone help to solve this?
Thanks in advance!
You can use triggers to check numeric using ISNUMERIC(), and throw error if not. But this is bad design because you are not using database constraint but trigger validation.
I still suggest you add a new checklist column where user select by themself if CK_limit is empty or not.
I think this is what you are looking for SQL_VARIANT_PROPERTY.
Or you can use client side validations or you can use stored procedures to track this.
Do not use isnumeric() for the constraint. For instance, isnumeric() accepts the following as valid numbers:
'$'
'.'
'-'
'3e4'
Instead, use try_convert(). You can do:
(try_convert(float, limit) is not null or
limit is null or
limit = ''
)
However, the right solution is to simply use the correct data type for the column. Don't store numeric values in strings.
I have a dimension called dim_Person. I have values in the Name column (or attribute) which contains danish characters. I have found out that if I have two rows in my datawarehouse table with the same name, but spelled in danish and english, I will get an error. For example:
Surrogate_Key FirstName
1 Ægir
2 Aegir
I will get an error, saying that my FirstName attribute with the value 'Aegir' fails as the cube cannot insert a dublicate key row.
Errors in the OLAP storage engine: A duplicate attribute key has been found when processing: Table: 'dim_Person', Column: 'FirstName', Value: 'Aegir'. The attribute is 'First Name'.
I have figured out that if I change all 'Ægir' to 'Aegir' (or vice versa) in my datawarehouse source table I have no problems processing the dimension. But if the two names co-exists it will not process.
I assume that behind the scenes, all values are stored in an (for the developer) unknown table. It is as if it looks up: Does the value 'Aegir' exists? and get a 'no it does not' returned. Then it tries to insert the value, but the 'Ae' is converted to an 'Æ' (or vice versa) and then it fails.
For the moment I have converted all special characters in the source table to english characters, but I would like to know: is there a way I can set up my project so the two names can co-exists in the same dimension?
I have the exact same problem with Æ and get the same error message when trying to process the SSAS dimension. In my case, the problem is the Danish city of: Vedbæk
And I solved it: I changed the collation property (Properties -> KeyColumns -> [open up the attribute] -> Collation) from Accent Sensitive to Binary 2
I found a couple threads on this topic but the answers seemed a little too complex for what I'm trying to do.
I am using SQL Developer and have a table, lets call it HR_Employees. This table I have to use to populate a fact table, we will call it Fact_Key. This fact table has 3 columns, including a description as well as the Employee_Key column (which is the primary key).
The task I have is to figure out a way to create the employee_key off of a Department_ID field. For half of the company this is automatically generated based on some payroll information and pushed into the Fact_Key table however for the other half (which is merging into the first half) they do not use the same payroll system so this wouldn't work for us. I have to take the Department_ID and use that to create an employee_key by concatenating it with other fields (employee_number for instance). See below:
INSERT INTO FACT_KEY (Employee_Key, Description)
SELECT RPAD(Employee_Number||Deptartment_ID, 15,'0'), EmployeeJob_Code
FROM HR_EMPLOYEES
I am padding this to keep all keys at a consistent 15 character length. The problem I am experiencing is the Employee_Key field is a numeric data type but the Department_ID has non-numeric characters in it at random places. I need a way to remove those characters or preferably change them into their ASCII counterparts. Is there a simple way to do this?
Everything I've seen appears too complex and I was looking for a simpler way to do this (involving just one or two functions) as this is going into a stored procedure and I was directed to keep it simple. Any help would be appreciated, Thanks!
Just use regexp_replace, example:
select REGEXP_REPLACE('123A45B67CCC89', '[^[:digit:]]','') from dual
returns: 123456789
I have the table with field title_medi which contains two rows like Mr. and Ms.
Also I have input field called title with search help of title_medi. When I'm selecting Mr. in the search help it gets displayed in the textfield.
If I compare that text field value with the database field. I'm getting an error.
But when I debug and see the value is somewhat getting converted to all uppercase like MR. not as exactly in the table.
Could you please help me out with this?
In order to solve this you have 2 options:
Go to the domain of the table field and check Lower case check this
Use TRANSLATE ABCD TO LOWER CASE before making the comparison check this
I checked the data element but that is also been checked with the lower case.
So what i did is i have checked the check-box for upper/lower case attribute in screen painter for the concern field. It works fine
additional info
In HR, possible quality (Mr, Ms...) are stored in table t522. Corresponding texts are stored in T522T. The data element is ANREX, associated with the domain of same name. This domain is lower case enabled.
moreover, this also give you the person's gender.
Use LOWER CASE addition to PARAMETERS, if you refer to selection screen input field.
PARAMETERS: p_matnr LIKE mara-matnr LOWER CASE.
I don't know which version OP was using as this is really old question, but this addition is available at least since ABAP 700 SP05
Due to a weird request, I can't put null in a database if there is no value. I'm wondering what can I put in the store procedure for nothing instead of null.
For example:
insert into blah (blah1) values (null)
Is there something like nothing or empty for "blah1" instead using null?
I would push back on this bizarre request. That's exactly what NULL is for in SQL, to denote a missing or inapplicable value in a column.
Is the requester experiencing grief over SQL logic with NULL?
edit: Okay, I've read your reply with the extra detail about this job assignment (btw, generally you should edit your original question instead of posting more information in an answer).
You'll have to declare all columns as NOT NULL and designate a special value in the domain of that column's data type to signify "no value." The appropriate value to choose might be different on a case by case basis, i.e. zero may signify nothing in a person_age column, but it might have significance in an items_in_stock column.
You should document the no-value value for each column. But I suppose they don't believe in documentation either. :-(
Depends on the data type of the column. For numbers (integers, etc) it could be zero (0) but if varchar then it can be an empty string ("").
I agree with other responses that NULL is best suited for this because it transcends all data types denoting the absence of a value. Therefore, zero and empty string might serve as a workaround/hack but they are fundamentally still actual values themselves that might have business domain meaning other than "not a value".
(If only the SQL language supported a "Not Applicable" (N/A) value type that would serve as an alternative to NULL...)
Is null is a valid value for whatever you're storing?
Use a sentry value like INT32.MaxValue, empty string, or "XXXXXXXXXX" and assume it will never be a legitimate value
Add a bit column 'Exists' that you populate with true at the same time you insert.
Edit: But yeah, I'll agree with the other answers that trying to change the requirements might be better than trying to solve the problem.
If you're using a varchar or equivalent field, then use the empty string.
If you're using a numeric field such as int then you'll have to force the user to enter data, else come up with a value that means NULL.
I don't envy you your situation.
There's a difference between NULLs as assigned values (e.g. inserted into a column), and NULLs as a SQL artifact (as for a field in a missing record for an OUTER JOIN. Which might be a foreign concept to these users. Lots of people use Access, or any database, just to maintain single-table lists.) I wouldn't be surprised if naive users would prefer to use an alternative for assignments; and though repugnant, it should work ok. Just let them use whatever they want.
There is some validity to the requirement to not use NULL values. NULL values can cause a lot of headache when they are in a field that will be included in a JOIN or a WHERE clause or in a field that will be aggregated.
Some SQL implementations (such as MSSQL) disallow NULLable fields to be included in indexes.
MSSQL especially behaves in unexpected ways when NULL is evaluated for equality. Does a NULL value in a PaymentDue field mean the same as zero when we search for records that are up to date? What if we have names in a table and somebody has no middle name. It is conceivable that either an empty string or a NULL could be stored, but how do we then get a comprehensive list of people that have no middle name?
In general I prefer to avoid NULL values. If you cannot represent what you want to store using either a number (including zero) or a string (including the empty string as mentioned before) then you should probably look closer into what you are trying to store. Perhaps you are trying to communicate more than one piece of data in a single field.