Elessar wrote:Do this issues still exist in Bedrock v3? If no, could you please sent me their description?
I doubt it; this was a very long time ago, before even V2 came out. I can't find the e-mail(s?) now; I can't recall whether it was before or after we moved from Exchange to Gmail (urgh...), but before, I suspect. I no longer have access to my ancient Exchange e-mails, short of putting in a request to the Help Desk. And Gmail insists that it can't find the e-mail in question, which could be either because:
(a) It was sent before we moved to GMail and was not part of the then-current mail swept across to it (which is quite possible); or
(b) For a company that built its name on a search engine the Gmail search is really, really woeful, though usually it's woeful in the way of returning dozens to hundreds of false positives rather than not being able to find anything at all.
The reason that I suspect that they're no longer an issue is that over the last few weeks I've been doing a review of all of the Bedrock code, making sure that I have a standardised version (i.e., V3) across all servers. I've only come across a couple of minor code issues which are so obscure that it would be exceedingly unlikely for anyone to stumble on them and which are so long winded that I'm not even going to bother typing them here at the moment.
The bigger issue is with the documentation, which needs an overhaul. The documentation for a bunch of processes refer to, for instance, a non-existent parameter called pSkipConsols. (Eg Bedrock.Cube.Data.Export and Bedrock.Cube.View.Create. Note that this is
not the same as the pSuppressConsol parameter, which serves a completely different purpose. ) That parameter does not seem to exist in any process at all. Obviously if someone includes it in a process call it will crash the call chain; calling a process with an unknown parameter drops it dead. Still, that's more an irritation than an error, and should be picked up in testing. In a similar vein the documentation keeps referring to a parameter named pDeleteTempObj whereas the real parameter name is pDestroyTempObj; again this is more than pedantry because if you use the wrong one, the call fails. A couple of the examples refer to incorrect process and/or parameter names, so copying and pasting them tends to result in a brief bout of mild swearing at runtime.
There are a couple of instances where the output does not work as advertised; for example Bedrock.Cube.Data.Export supposedly produces the following file: "If no file name is provided, a combination of the cube, dimension and element suffixed by 'export.csv' will be used." Yeah, no. That doesn't happen. It actually gets generated as
CubeName_Export.csv. That will only be a problem if the user generates multiple files using different dim / element combinations out of a single cube. They may be expecting separate files on each call but will instead get just one file which is constantly being overwritten. There's nothing wrong with the code as such (and the obvious way around it is to
specify the output file name)... but it's not doing what the documentation says it is.
But I haven't found any (substantial) issues with the actual code to date, so either I haven't reached the processes in question yet or, more likely, whatever it was was fixed in subsequent versions or just superseded by new processes.