Error Processing Cube on 64-bit server

We are in the process of migrating to a new 64-bit server. We changed the data provider for the cube from "Microsoft OLE DB Provider for Oracle" to ".Net Provider\OracleClient Data Provider" for the 64-bit and when we try and process this cube, we get the following error:

Errors in the high-level relational engine. The following exception occurred while the managed IDataReader interface was being used: Value was either too large or too small for a Currency..

This very same cube was able to process on the 32-bit server just fine. The field that the error refers to is a number(28,0) in oracle and is fully populated in the database. I set up a simple cube on my laptop and if I cut the value in the field down to 15 numbers it will process correctly. I have maxed out the precision of the number type to 38 as well and I am still getting the error when more than 15 numbers are populated in a single field.

Does anyone know what is keeping the cube from processing with ODP.Net when it is processing fine with the other data provider?

This has to do with the conversion of that data type in the Oracle Provider, Analysis Services wouldn't be generating that error, it would be just passing it on. I would consult with Oracle to find out more regarding it.

Is the data type in the dimension or Fact for this field Currency? If so you may want to change it in AS so there is no conversion.

David

Error on Migrating to V2000 SQL from V7

I have just upgraded to SQL 2000 as per the companies allowed versions and
when trying to run an Stored Procedure I am getting the following error.
Syntax error converting the varchar value '2165.05' to a column of data type
int.
The Stored Proc just selects values into a Table, the wierd thing is this
works on v7 (same data / schema everything, but not on 2000) I can code
around it with Convert etc but was wondering if its a common problem and if
there is anything more I should know.
Cheers
Stumpy
Message posted via http://www.droptable.com
Without seeing a repro, I can only guess. It could be that datatype precedence has changed. Say, for
instance, you have a column of datatype varchar and a variable of datatype nvarchar, and then do:
WHERE col = @.a
7.0 would convert the value side to the column sides datatype. But 2000 will go by the rules
specified in Books Online "Datatype Precedence", and above would result in converting the column
side to the value sides datatype.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"stumpy_uk via droptable.com" <u15773@.uwe> wrote in message news:75df584d107f7@.uwe...
>I have just upgraded to SQL 2000 as per the companies allowed versions and
> when trying to run an Stored Procedure I am getting the following error.
> Syntax error converting the varchar value '2165.05' to a column of data type
> int.
> The Stored Proc just selects values into a Table, the wierd thing is this
> works on v7 (same data / schema everything, but not on 2000) I can code
> around it with Convert etc but was wondering if its a common problem and if
> there is anything more I should know.
> Cheers
> Stumpy
> --
> Message posted via http://www.droptable.com
>
|||MS changed the rules for implicit date type converstion between V7 and 2000.
There is nothing you can do about it.
If you use a char data type in a context in which a numeric type is
required, the char value will be converted to int, unless the context
explicitly implies (sic!) that decimal or float is requied. Since 2165.05 is
not an int, but a decimal, the conversion will fail. Since you fail to
provide the SQL code, there's no chance of my giving more details.
Use CAST (val as decimal (18, 2)) [or whatever data type you want] to
resolve. Note: CONVERT is an MS-specific function, so CAST is preferable.
"stumpy_uk via droptable.com" <u15773@.uwe> wrote in message
news:75df584d107f7@.uwe...
>I have just upgraded to SQL 2000 as per the companies allowed versions and
> when trying to run an Stored Procedure I am getting the following error.
> Syntax error converting the varchar value '2165.05' to a column of data
> type
> int.
> The Stored Proc just selects values into a Table, the wierd thing is this
> works on v7 (same data / schema everything, but not on 2000) I can code
> around it with Convert etc but was wondering if its a common problem and
> if
> there is anything more I should know.
> Cheers
> Stumpy
> --
> Message posted via http://www.droptable.com
>
|||Thanks all for your help, sorry I didn't post the DDL etc, the problem was
ownership of the Database in the end.I did a ChangeDBOwner on all the tables
and the problem went away.
Cheers for all the help..
Lee
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200707/1

Error on Migrating to V2000 SQL from V7

I have just upgraded to SQL 2000 as per the companies allowed versions and
when trying to run an Stored Procedure I am getting the following error.
Syntax error converting the varchar value '2165.05' to a column of data type
int.
The Stored Proc just selects values into a Table, the wierd thing is this
works on v7 (same data / schema everything, but not on 2000) I can code
around it with Convert etc but was wondering if its a common problem and if
there is anything more I should know.
Cheers
Stumpy
Message posted via http://www.droptable.comWithout seeing a repro, I can only guess. It could be that datatype preceden
ce has changed. Say, for
instance, you have a column of datatype varchar and a variable of datatype n
varchar, and then do:
WHERE col = @.a
7.0 would convert the value side to the column sides datatype. But 2000 will
go by the rules
specified in Books Online "Datatype Precedence", and above would result in c
onverting the column
side to the value sides datatype.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"stumpy_uk via droptable.com" <u15773@.uwe> wrote in message news:75df584d107f7@.uwe...[vbcol
=seagreen]
>I have just upgraded to SQL 2000 as per the companies allowed versions and
> when trying to run an Stored Procedure I am getting the following error.
> Syntax error converting the varchar value '2165.05' to a column of data ty
pe
> int.
> The Stored Proc just selects values into a Table, the wierd thing is this
> works on v7 (same data / schema everything, but not on 2000) I can code
> around it with Convert etc but was wondering if its a common problem and i
f
> there is anything more I should know.
> Cheers
> Stumpy
> --
> Message posted via http://www.droptable.com
>[/vbcol]|||MS changed the rules for implicit date type converstion between V7 and 2000.
There is nothing you can do about it.
If you use a char data type in a context in which a numeric type is
required, the char value will be converted to int, unless the context
explicitly implies (sic!) that decimal or float is requied. Since 2165.05 is
not an int, but a decimal, the conversion will fail. Since you fail to
provide the SQL code, there's no chance of my giving more details.
Use CAST (val as decimal (18, 2)) [or whatever data type you want] to
resolve. Note: CONVERT is an MS-specific function, so CAST is preferable.
"stumpy_uk via droptable.com" <u15773@.uwe> wrote in message
news:75df584d107f7@.uwe...
>I have just upgraded to SQL 2000 as per the companies allowed versions and
> when trying to run an Stored Procedure I am getting the following error.
> Syntax error converting the varchar value '2165.05' to a column of data
> type
> int.
> The Stored Proc just selects values into a Table, the wierd thing is this
> works on v7 (same data / schema everything, but not on 2000) I can code
> around it with Convert etc but was wondering if its a common problem and
> if
> there is anything more I should know.
> Cheers
> Stumpy
> --
> Message posted via http://www.droptable.com
>|||Thanks all for your help, sorry I didn't post the DDL etc, the problem was
ownership of the Database in the end.I did a ChangeDBOwner on all the tables
and the problem went away.
Cheers for all the help..
Lee
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200707/1sql

Error on Migrating to V2000 SQL from V7

I have just upgraded to SQL 2000 as per the companies allowed versions and
when trying to run an Stored Procedure I am getting the following error.
Syntax error converting the varchar value '2165.05' to a column of data type
int.
The Stored Proc just selects values into a Table, the wierd thing is this
works on v7 (same data / schema everything, but not on 2000) I can code
around it with Convert etc but was wondering if its a common problem and if
there is anything more I should know.
Cheers
Stumpy
--
Message posted via http://www.sqlmonster.comWithout seeing a repro, I can only guess. It could be that datatype precedence has changed. Say, for
instance, you have a column of datatype varchar and a variable of datatype nvarchar, and then do:
WHERE col = @.a
7.0 would convert the value side to the column sides datatype. But 2000 will go by the rules
specified in Books Online "Datatype Precedence", and above would result in converting the column
side to the value sides datatype.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"stumpy_uk via SQLMonster.com" <u15773@.uwe> wrote in message news:75df584d107f7@.uwe...
>I have just upgraded to SQL 2000 as per the companies allowed versions and
> when trying to run an Stored Procedure I am getting the following error.
> Syntax error converting the varchar value '2165.05' to a column of data type
> int.
> The Stored Proc just selects values into a Table, the wierd thing is this
> works on v7 (same data / schema everything, but not on 2000) I can code
> around it with Convert etc but was wondering if its a common problem and if
> there is anything more I should know.
> Cheers
> Stumpy
> --
> Message posted via http://www.sqlmonster.com
>|||MS changed the rules for implicit date type converstion between V7 and 2000.
There is nothing you can do about it.
If you use a char data type in a context in which a numeric type is
required, the char value will be converted to int, unless the context
explicitly implies (sic!) that decimal or float is requied. Since 2165.05 is
not an int, but a decimal, the conversion will fail. Since you fail to
provide the SQL code, there's no chance of my giving more details.
Use CAST (val as decimal (18, 2)) [or whatever data type you want] to
resolve. Note: CONVERT is an MS-specific function, so CAST is preferable.
"stumpy_uk via SQLMonster.com" <u15773@.uwe> wrote in message
news:75df584d107f7@.uwe...
>I have just upgraded to SQL 2000 as per the companies allowed versions and
> when trying to run an Stored Procedure I am getting the following error.
> Syntax error converting the varchar value '2165.05' to a column of data
> type
> int.
> The Stored Proc just selects values into a Table, the wierd thing is this
> works on v7 (same data / schema everything, but not on 2000) I can code
> around it with Convert etc but was wondering if its a common problem and
> if
> there is anything more I should know.
> Cheers
> Stumpy
> --
> Message posted via http://www.sqlmonster.com
>|||Thanks all for your help, sorry I didn't post the DDL etc, the problem was
ownership of the Database in the end.I did a ChangeDBOwner on all the tables
and the problem went away.
Cheers for all the help..
Lee
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200707/1

Error Migrating Reporting Services

I am migrating our reporting services from 2000 to 2005. I am following the instructions in http://msdn2.microsoft.com/en-us/library/ms143724.aspx. I am currently using the Report Server Configuration tool to restore the encryption key. I click "Restore", point to the backup that I created at the beginning of the process, enter the password, and the process begins. I get a check mark and a message saying "Restoring Encryption Key." The problem is that it never comes back from this. I let it run for over an hour and finally clicked one of the previous steps to abort this. I went back and started it over. Again, it has been running for over an hour. I get no errors; it just does not complete. How do I proceed? Thanks in advance for any assistance.

It sounds like you may have hit a bug in the tool. There is also a command line tool that should work. It is called rskeymgmt.exe and should be in your path.

Select rskeymgmt.exe /? to get all of the options. You will need at least -a -i -f -p and -u -v if not logged in as admin.

|||Thanks greatly. That did the trick.|||

Hi,

I want to migrate from an existing ReportServer 2000 to a new ReportServer 2005. For the new ReportServer I want to backup the encryption Key via rskeymgmt.exe.

My command looks like this:

rskeymgmt.exe -e -f c:\backup.key -p Password

Buy everytime I want to execute the command, I′ll get a very strange error:

Unexpected database error (-2147159548) 0x80040e14

With tracing enabled i am getting the following error:

System.Exception: Unexpected database error (-2147159548) 0x80040e14 > System.Exception: 0
End of inner exception stack trace
at Microsoft.ReportingServices.RSKeyMgmt.RSKeyMgmt.InstanceMain()
at Microsoft.ReportingServices.BaseCmdLine.CommandLineMain(String[] args, BaseCmdLine instance)

I have full admin rights on the server.

The ReportServer database lies on a different server on which I also have admin rights.

What I am doing wrong?

Best regards,

Peter

Error Migrating Reporting Services

I am migrating our reporting services from 2000 to 2005. I am following the instructions in http://msdn2.microsoft.com/en-us/library/ms143724.aspx. I am currently using the Report Server Configuration tool to restore the encryption key. I click "Restore", point to the backup that I created at the beginning of the process, enter the password, and the process begins. I get a check mark and a message saying "Restoring Encryption Key." The problem is that it never comes back from this. I let it run for over an hour and finally clicked one of the previous steps to abort this. I went back and started it over. Again, it has been running for over an hour. I get no errors; it just does not complete. How do I proceed? Thanks in advance for any assistance.

It sounds like you may have hit a bug in the tool. There is also a command line tool that should work. It is called rskeymgmt.exe and should be in your path.

Select rskeymgmt.exe /? to get all of the options. You will need at least -a -i -f -p and -u -v if not logged in as admin.

|||Thanks greatly. That did the trick.

error migrating olap db from analysis server (SQL Server 2000)

Hi there, I try to migrate olap db to Analysis Services 2005, and error shows :
Error Messages 6164
Errors in the OLAP storage engine: The attribute key cannot be found:
Table: dbo_Dim_Proper, Column: Kode_x0020_Proper, Value: 1632001. Errors in
the OLAP storage engine: The record was skipped because the attribute key was
not found. Attribute: Kode Proper attribute of Dimension: Dim_Proper from
Database: BTN, Cube: PLM191, Measure Group: PLM191, Partition: PLM191,
Record: 4.
Errors in the OLAP storage engine: The attribute key cannot be found:
Table: dbo_Dim_Proper, Column: Kode_x0020_Proper, Value: 1632001. Errors in
the OLAP storage engine: The record was skipped because the attribute key was
not found. Attribute: Kode Proper attribute of Dimension: Dim_Proper from
Database: BTN, Cube: PLM191, Measure Group: PLM191, Partition: PLM191,
Record: 7.
Any idea ? Thanks!
R'gards
Octoni
By default, AS2005 read the fact table without doing any join between this
table and related dimensions.
So by default AS2005 is "optimized", a step that you must manually do in
AS2000.
in AS2000 by default a query like select ... from table a inner join dimA
... is executed.
So what's appends in your case, there is some keys in your fact table but
these keys doesn't exists in your dimension table. with AS2000, the inner
join will automatically exclude these rows in errors during the process.
Because AS2005 don't do this inner join, these missing keys raise an error.
there is many solutions:
first, validate your dimension to insure that these keys exists, if not
create these keys in your database. (most beautyfull solution)
you can also ignore any key error.
or you can tell AS2005 to automatically create an "unknown" member for your
missing keys. (new AS2005 feature)
"octoni" <octoni@.discussions.microsoft.com> wrote in message
news:60D2BF3C-C34A-4BA6-A2CE-A3B705A99181@.microsoft.com...
> Hi there, I try to migrate olap db to Analysis Services 2005, and error
> shows :
> Error Messages 6164
> Errors in the OLAP storage engine: The attribute key cannot be found:
> Table: dbo_Dim_Proper, Column: Kode_x0020_Proper, Value: 1632001. Errors
> in
> the OLAP storage engine: The record was skipped because the attribute key
> was
> not found. Attribute: Kode Proper attribute of Dimension: Dim_Proper from
> Database: BTN, Cube: PLM191, Measure Group: PLM191, Partition: PLM191,
> Record: 4.
> Errors in the OLAP storage engine: The attribute key cannot be found:
> Table: dbo_Dim_Proper, Column: Kode_x0020_Proper, Value: 1632001. Errors
> in
> the OLAP storage engine: The record was skipped because the attribute key
> was
> not found. Attribute: Kode Proper attribute of Dimension: Dim_Proper from
> Database: BTN, Cube: PLM191, Measure Group: PLM191, Partition: PLM191,
> Record: 7.
>
> Any idea ? Thanks!
> R'gards
> Octoni

error migrating olap db from analysis server (SQL Server 2000)

Hi there, I try to migrate olap db to Analysis Services 2005, and error show
s :
Error Messages 6164
Errors in the OLAP storage engine: The attribute key cannot be found:
Table: dbo_Dim_Proper, Column: Kode_x0020_Proper, Value: 1632001. Errors in
the OLAP storage engine: The record was skipped because the attribute key wa
s
not found. Attribute: Kode Proper attribute of Dimension: Dim_Proper from
Database: BTN, Cube: PLM191, Measure Group: PLM191, Partition: PLM191,
Record: 4.
Errors in the OLAP storage engine: The attribute key cannot be found:
Table: dbo_Dim_Proper, Column: Kode_x0020_Proper, Value: 1632001. Errors in
the OLAP storage engine: The record was skipped because the attribute key wa
s
not found. Attribute: Kode Proper attribute of Dimension: Dim_Proper from
Database: BTN, Cube: PLM191, Measure Group: PLM191, Partition: PLM191,
Record: 7.
Any idea ? Thanks!
R'gards
OctoniBy default, AS2005 read the fact table without doing any join between this
table and related dimensions.
So by default AS2005 is "optimized", a step that you must manually do in
AS2000.
in AS2000 by default a query like select ... from table a inner join dimA
... is executed.
So what's appends in your case, there is some keys in your fact table but
these keys doesn't exists in your dimension table. with AS2000, the inner
join will automatically exclude these rows in errors during the process.
Because AS2005 don't do this inner join, these missing keys raise an error.
there is many solutions:
first, validate your dimension to insure that these keys exists, if not
create these keys in your database. (most beautyfull solution)
you can also ignore any key error.
or you can tell AS2005 to automatically create an "unknown" member for your
missing keys. (new AS2005 feature)
"octoni" <octoni@.discussions.microsoft.com> wrote in message
news:60D2BF3C-C34A-4BA6-A2CE-A3B705A99181@.microsoft.com...
> Hi there, I try to migrate olap db to Analysis Services 2005, and error
> shows :
> Error Messages 6164
> Errors in the OLAP storage engine: The attribute key cannot be found:
> Table: dbo_Dim_Proper, Column: Kode_x0020_Proper, Value: 1632001. Errors
> in
> the OLAP storage engine: The record was skipped because the attribute key
> was
> not found. Attribute: Kode Proper attribute of Dimension: Dim_Proper from
> Database: BTN, Cube: PLM191, Measure Group: PLM191, Partition: PLM191,
> Record: 4.
> Errors in the OLAP storage engine: The attribute key cannot be found:
> Table: dbo_Dim_Proper, Column: Kode_x0020_Proper, Value: 1632001. Errors
> in
> the OLAP storage engine: The record was skipped because the attribute key
> was
> not found. Attribute: Kode Proper attribute of Dimension: Dim_Proper from
> Database: BTN, Cube: PLM191, Measure Group: PLM191, Partition: PLM191,
> Record: 7.
>
> Any idea ? Thanks!
> R'gards
> Octoni