}bedrock.cube.data.import

Question

}bedrock.cube.data.import

CJRothman opened this issue 2 years ago · 7 comments

Describe the bug
I'm trying to use this TI to export (using Bedrock4) attribute cubes and import into another instance and I am incurring errors. I had to edit the 1st section (If( nDimensionCount = 2 );) in order to import attributes.
The TI counts the number of dimensions in the target cube as nDimensionCount.
Then, in the Data tab, we have multiple sections of code (depending on nDimensionCount) that populate the target cube. Below is one of those sections that has not been edited by me. If we only have 3 dimensions in the target cube, how is it that we are referring to v4 and what hapenned to v1? v4 should be the value (not v5) as opposed to being referred to as the 3rd dimension.

Answer 1 · 2023-01-12T18:07:02.000Z

Hello, Just throwing an option out there without looking in the code itself. Typically, V1 could be the cubename, perhaps including the server name and a colon. Then it makes sense to skip V1 and real date starts in the second column. Is this what is happening ? Op do 12 jan. 2023 om 17:28 schreef Chris Rothman ***@***.***>

*Describe the bug* I'm trying to use this TI to export (using Bedrock4) attribute cubes and import into another instance and I am incurring errors. The TI counts the number of dimensions in the target cube as nDimensionCount. Then, in the Data tab, we have multiple sections of code (depending on nDimensionCount) that populate the target cube. Below is one of those sections that has not been edited by me. If we only have 3 dimensions in the target cube, how is it that we are referring to v4 and what hapenned to v1? ElseIf( nDimensionCount = 3 ); If( CellIsUpdateable( pCube, v2, v3, v4 ) = 1 ); sElType = DType( sDim3, v4 ); If( sElType @<> 'S' ); IF(pCumulate = 1); nObal = CellGetN( pCube, v2, v3, v4 ); nCbal = nObal + StringToNumber( v5 ); ELSE; nCbal = StringToNumber( v5 ); Endif; CellPutN( nCbal, pCube, v2, v3, v4 ); Else; CellPutS( v5, pCube, v2, v3, v4 ); EndIf; EndIf; ElseIf( nDimensionCount = 4 ); — Reply to this email directly, view it on GitHub <#345>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDHULKV3DRL2C6VW7RPPDTWSAWJRANCNFSM6AAAAAATZOF4KI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

--

…

------ Best regards / Beste groeten, Wim Gielis MS Excel MVP 2011-2014 https://www.wimgielis.com <http://www.wimgielis.be>

Answer 2 · 2023-01-12T18:32:31.000Z

Are the errors due to attributes not existing or being typed differently between the instances? Becasue although the cube.data.import process has special cases for 2 dimensional cubes to check for attribute cubes, security cubes, etc. (and also for 3 dimension cubes in the case of localized attribute cubes for that matter). It doesn't do anything like check if the attribute exists and create it. It is assumed that what's being imported is valid for the destination.

Given that the screenshot doesn't show the special case for a localized attribute cube you aren't using the latest version (so considder upgrading).

In the standard export format (which is the same as if you right click a cube and "export as text data" in the old clients as a "cma" file the first field is always the cube name. This is ignored by the import process. Hence dimension 1 is v2.

Answer 3 · 2023-01-12T23:53:47.000Z

I was just going to respond to your question but I see you closed the issue already. Was I missing something or has an updated version already been published?
It had nothing to do with attributes not existing or being typed differently.
The files that were exported using Bedrock4 did not have cube in column 1 and so all the dimension references are off by 1.
The CellisUpdateable command is referencing dimension 1 as v2.

Answer 4 · 2023-01-13T00:03:44.000Z

Do you export data with pCubeNameExport = 1 ? (at least, different from 0) The import process assumes this format, as can be read in the Prolog tab.

…

------ Best regards / Beste groeten, Wim Gielis MS Excel MVP 2011-2014 https://www.wimgielis.com <http://www.wimgielis.be> Op vr 13 jan. 2023 om 00:53 schreef Chris Rothman ***@***.***

: I was just going to respond to your question but I see you closed the issue already. Was I missing something or has an updated version already been published? It had nothing to do with attributes not existing or being typed differently. The files that were exported using Bedrock4 did not have cube in column 1 and so all the dimension references are off by 1. The CellisUpdateable command is referencing dimension 1 as v2. — Reply to this email directly, view it on GitHub <#345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDHULLVJ6PMCSIOES27WYLWSCKRNANCNFSM6AAAAAATZOF4KI> . You are receiving this because you commented.Message ID: ***@***.***>

Answer 5 · 2023-01-13T00:12:20.000Z

My pCubeNameExport was set to 0 (which I didn't change) but it DID skip cube name.
Then there should be a matching parameter on the import TI.
It's counterintuitive that it includes the cube name if set to 1 as the descript is
OPTIONAL: Skip cube name from export file, including header (Skip = 0) (Default = 1)

Answer 6 · 2023-01-13T00:17:53.000Z

The way I see it is also like that, although I just looked at it briefly. Let’s wait for Lotsaram to weigh in on this one. Op vr 13 jan. 2023 om 01:12 schreef Chris Rothman ***@***.***>

No. Then there should be a matching parameter on the import TI or it should atleast default to a 1 on the export side. — Reply to this email directly, view it on GitHub <#345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDHULPOW6DS43IB3KFYL5DWSCMW7ANCNFSM6AAAAAATZOF4KI> . You are receiving this because you commented.Message ID: ***@***.***>

--

…

------ Best regards / Beste groeten, Wim Gielis MS Excel MVP 2011-2014 https://www.wimgielis.com <http://www.wimgielis.be>

Answer 7 · 2023-01-13T09:47:00.000Z

@CJRothman there was a bug that the default value of pCubeNameExport was set to 0 not 1 so behavior if this param was ommitted was not backwards compatible. But this was fixed in #341

I don't see an immediate need to update cube.data.import to work with both formats. Although it wouldn't be that difficult just add If( pCubeNameExport = 0 ); v30 = v29; v29 = v28; ... v2 = v1; EndIf; to the start of the data tab.
If you want to raise a ER for this then please do. And/or submit a pull request with the fix.

But the bug in this case has been fixed. All you need to do is download the latest version (not the last release). Or to apply local fix just save the process with the correct default value of 1.