PaulSimon wrote:
I can confirm that the bug whereby editing a chore advances the time by an hour is still there in 9.1.4, but I haven't been able to make it happen in 9.4
I don't have a 9.1 environment available, but I agree that I can't get it to happen in 9.4 either. (I can in 9.0 SP3, though.) I don't know whether the "gets bumped by a day if you're on a different UTC day" bug happens in 9.4; I'll have to test that in the morning. (
Edit: Seems to have been fixed by 9.0. Alas the use of different icons to indicate whether a chore is active only came in in a later version.)
PaulSimon wrote:
As far as creating a View that users cannot see for use in TI, there are a few options:
The ViewCreate(vCube,'}Temp') method works. However, the downside is that you cannot create or delete the View in Server Explorer. You have to do it in TI. Users who turn on Display Cubes can still see the View. I am also a little uncomfortable about creating Control objects, when TM1 itself uses this method for its only Control objects. I suspect that it may lead to bugs, and TM1 has enough of those already without encouraging it, but then so does every other bit of software I've worked on.
Oh I hear thee. And concur with thee.
PaulSimon wrote:
If you create the View in the Prolog and destroy it in the Epilog, then effectively it is not available to the user, short of a mid-process crash. However, creating a View with a full set of skipzeroes, and appropriate subset creation, etc, can lead to very long Prologs.
My own view is that the "create and destroy" approach is the best one out there, though we typically use separate processes to handle creation of the subsets and creation of the views. This allows us greater ability to abort if things go pear shaped for any reason. I'm not fussed about the length of the code in lines; our subset creation code is over 500 lines long (covering pretty much any type of subset we could need) but customising it is verboten. The intention is that the standard code can be copied and pasted into any subset creation process and we don't need to read the code to see how it works; just the variable assignments. The code itself executes almost instantaneously, though, so we don't care about the line length.
However Steve Vincent indicated that use of temporary views was a problem in 9.0:
http://forums.olapforums.com/viewtopic. ... 032&p=5800
Steve Vincent wrote:Alan Kirk wrote:
Not unless it uses a pre-defined view or subset as a data source (which would be bad practice)
Slight aside, but some of us are stuck with predefined views due to a bug in 9.0 which was fixed "somewhere" in 9.1, where a TI used to create a temp view corrupts it. In those cases you are stuck with predefined views and the need to copy them and any relevant subsets with them too
I asked whether this was an intermittent or permanent bug but didn't get an answer, though what I
can say is that I've yet to be able to reproduce it myself in a 9.0 U3 environment. All of our chores which create a temporary view, move data using it and then destroy it seem to work fine under 9.0. 9.0 is the version that I'm thinking of upgrading to, so that was a big issue for us.
PaulSimon wrote:
Personally, I have long since adopted the standard of naming Views that are only intended for system purposes so that they start with a 'z'. Users know not to try to open a View that starts with a 'z', and if they do, then the worst that will happen is that they will get an out of memory message. In most companies I have worked in, it is only the core users who use Server Explorer directly. The general users just use prepared spreadsheets for monthly reports and forecast entry, so they never delve in to Server Explorer anyway.
I wish that Cognos would bring back the split that they had in version 6, where Views designed for viewing, were different objects to Queries which were designed for exporting. If you look at the TM1 API, in reality the two objects are different anyway. A Query type View can only have Rows, not Columns or Titles, as a Display View can. A Query type View can have Skip Consols, Skip Calcs, and Skip Zeros, which is a similar but different property to suppress Zeros in a Display View. Also a Query View can have query contraints eg a >= 10. If we had different object types, then a lot of these problems would go away.
Yes, I think that was what the person who raised it in the legendary Christmas Wishlist on the old Forum was getting at. (I thought that it was another of the regulars, but it was Dan Bernatchez, actually. (Though seconded by Garry Cook.) Dan was a regular on the old Forum but doesn't seem to inhabit these parts unless he does so under a nom de plume.) I don't think that you'll get anyone disagreeing with you on all of the points that you've raised; it's less a question of the potential problems that having the two grouped together can cause (as you say, usually the worst that will usually happen is an out of memory message; though I really would prefer that Iboglix change that message because many users think it's a system error), but at least it would de-clutter the Views list and keep it limited to the things that really ARE "Views".
Alan Kirk wrote:
However that I have no problem with the use of UTC for log files given that it's necessary to synchronise servers across time zones.
Y'know what? While I'm at it, I'm going to recant that view as well; I
do have a problem with it, because it's another piece of pointless, badly implemented design which makes life more problematic than it needs to be.
Yes, log times
do need to be recorded in UTC (or GMT as Iboglix prefer to refer to it) to allow servers to be synced, I still understand that. But the log file has TWO date fields, not one, and at present they BOTH record the data in UTC. That means that you get bloated log files and for what? Not a thing. Where I come from that's called data redundancy, and is not generally viewed as being a virtue. Why on Earth the first field couldn't have been implemented as being either Local or UTC
according to user choice, with the system free to use the second field (which is, after all, actually headed Replication Time) for replication, I have no idea. In 9.4 at least you can set the server log file (as opposed to the transaction log file) according to choice via the tm1s-log.properties config file. But not the transaction log file, that'd be too convenient. Unless of course there's some hidden parameter to do it, which also wouldn't surprise me in the least but certainly I can't find one in the 9.4 .pdfs.
When a user asks us to check when an entry was done, we have two ways of doing it. One is to query the log files directly from Server Explorer. The down side is that it allows you to search for only a single element in each dimension. Some people claim that it also ties up the server, though I've never experienced that in 8.2.12; I've also found it remarkably fast. However then come the mental timezone gymnastics. "Uh, OK, so if that was entered at 23:15 on Wednesday UTC, then it must have been, um, Tuesday, no, wait, we're a day ahead, Thursday here, so that's, uh, hang on is it +10 hours or +11 in the month that value was entered..."
The other way is to query the Access database application that I've written to store our log files in. The advantage is that (a) we can do fully flexible queries with multiple conditions and (b) I have a function that I wrote based on the Windows API which translates the UTC times into local times. Of course since the Windows API only returns transition information for daylight savings times, and only for the current period, and given that local and regional governments like to shift around DST transition dates on whatever whim they may have dreamed up that season (usually relating to some half baked sporting event which is forgotten by 95% of the population 5 minutes after it happened), it's important to ensure that the files are uploaded as soon as possible.
And of course the down side is that Access is teeth-grindingly slow.
But noooo, couldn't have that first field storing Local time information to get around some of these problems, nope, too much effort, that. Notwithstanding the fact that it's available for the server log suggests that SOMEONE in Iboglix clued into the fact that for a LOT of people, Local time really is going to be the more relevant piece of information.