Chores & Daylight Saving Time

Post Reply
Lukas Meyer
Posts: 51
Joined: Thu Jul 24, 2008 6:14 am

Chores & Daylight Saving Time

Post by Lukas Meyer »

Hello,
I barely remember some funny issue involving daylight saving time and chores not running as expected.
I remember a chore scheduled in January will - if disabled and edited - always add an extra hour to the start time each time it is checked. Can be solved by setting the start-date to the current day.

My question is: Will a chore I start today, scheduled for 6:40 am, run all year long as expected (at 6:40 system time on the machine) if I no one touches it ever?

(Every fiber screams "hell, yes" - but on the other hand it's TM1 - so I'm not sure and in this specific case of mine timing is crucial)

thank you,
Lukas
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: Chores & Daylight Saving Time

Post by Alan Kirk »

Lukas Meyer wrote:Hello,
I barely remember some funny issue involving daylight saving time and chores not running as expected.
I remember a chore scheduled in January will - if disabled and edited - always add an extra hour to the start time each time it is checked. Can be solved by setting the start-date to the current day.

My question is: Will a chore I start today, scheduled for 6:40 am, run all year long as expected (at 6:40 system time on the machine) if I no one touches it ever?

(Every fiber screams "hell, yes" - but on the other hand it's TM1 - so I'm not sure and in this specific case of mine timing is crucial)
{To the regulars:} Ahem, stand aside gentlemen, let me field this one.

Lukas, I'm afraid that every fibre in your body is dead wrong.

In a piece of mind-boggling and flat out wrong-headedness which TRANSCENDS THE FRAPPING BOUNDARIES OF BELIEF, Applix took it upon themselves to make a change between version 7 (where chores were scheduled on local time) and version 8 (where they were scheduled in UTC time). That means that not only will you have problems if you schedule a chore with a start date which occurs after your next Daylight Savings transition (or before your last one), not ONLY that, my friend, but EACH AND EVERY NAFFING TIME, twice per year, that you go on or off DST you have to go and reschedule any chores which run at a designated time. The only ones that you can avoid doing that with are ones which run say each hour (half hour, 15 minutes, whatever), or ones which run in the wee small hours where an hour either way won't make a difference.

The solutions are:
(a) When you schedule a chore, make sure that its start time is in the same daylight savings season as the one that you're currently in;
(b) Make a note in Outlook to reschedule your chores on the Monday morning after you go on or off DST;
(c) Buy a punching bag, put a sign reading "THANK YOU APPLIX!" on it, and kick the bejebbers out of it when you have completed step (b).
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: Chores & Daylight Saving Time

Post by Alan Kirk »

Lukas Meyer wrote: My question is: Will a chore I start today, scheduled for 6:40 am, run all year long as expected (at 6:40 system time on the machine) if I no one touches it ever?
Ah, one other "gotcha" that you should be aware of as well, though this may have been fixed in more recent versions than 8.2.12. If we schedule a chore which is due to run weekly, we need to make sure that we're on the same local day as the UTC day. (UTC is like Greenwich Mean Time. It's kinda-roughly-sorta the same thing (at least for day to day purposes), but calculated differently.)

For example, in Eastern Australia in the middle of winter our timezone is UTC + 10 hours. That means that on a Tuesday morning local time, up until 10am the UTC date is still Monday. If we schedule a chore to run once each week between the time we get in and 10am, it's likely to be assigned to the wrong day. This is because of a glitch in the calculation method between local time and UTC time. Those closer to the Prime Meridian often aren't affected by this since they're close enough to UTC for them to seldom be on a different day. On the other side of the world, it obviously has much more impact.

Changing the time of a chore is also fun because Excel will randomly drop like a brick when you make the change presumably due to shoddy error handling in the relevant API functions.

Post script: For your next question you may want to consider asking whether there's an undo function for data spreading, for which answer I shall yield the floor to the Honourable member for Lytham. After that you can ask whether it's possible to create a public view for data exports which is protected from the unsuspecting gaze of end users. Sad to say, I can't recall which of our august crew is the specialist on that topic, though it's caused enough grief for everyone from time to time. :)

(For those new to the Forum, most of the long-term regulars has at least one issue with TM1 which bugs the bewhatsists out of them. Having to waste time rescheduling chores every 6 months and having Excel randomly crash on me when I do so is my particular area.)
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
Lukas Meyer
Posts: 51
Joined: Thu Jul 24, 2008 6:14 am

Re: Chores & Daylight Saving Time

Post by Lukas Meyer »

Thank you so much Alan - everyone in my little office laughed when I told them I would ask in forums if the crazy thing I thought I remembered about Chores not working as any human being with an ounce of common sense thought they would work. So FREE LUNCH for me (which is great when you are some kind of underpaid poor student - but I think I'll always be underpaid, no matter what I get payed :D)

We have GMT+1 here, so no day-crossing problems :)

"create a public view for data exports which is protected from the unsuspecting gaze of end users"
I create those Views in the prologue and name them "_DO_NOT_OPEN_(processname)_(now*10000000000)" and delete them in the epilog. So after a month I have some fine views to delete - unless some other admin got tired of them and deleted them :) (mostly without killing the subsets named exactly the same...)
You surely know, that the properties-pane makes it possible to select 8and delete) multiple elements, which isn't possible in the tree-view. I'm amazed how many people don't know the latter :)

(As a matter of fact I "work" with/for TM1 for ("since" could be applied somehow - TM1 bothers me during nights sometimes) three years - but this is the first time a chores timing is important.)

PS.:

Tired of stopping your server the usual ways? Try this:

IF(1=2);
#if this is executed, you should restart your machine
#oh, and division by 0 may work in this block too!
cube = 'readalittlestoryofmine;
ENDIF;
CELLPUTN(1,cube,'onceuponatimetherewasalittletm1server','hetriedtoexecutethis');
#and he never ever reached this line.
#poor TM1 server - he tried so hard :(

Always fun - put it in a process and give it a trainee to debug. He won't bother you the rest of the day ;D
(well, remove the comments - otherwise he will figure it out sooner or later...)

greetings from my 30°C office in Austria in the shade
Lukas
User avatar
LoadzaGrunt
Posts: 72
Joined: Tue May 26, 2009 2:23 am
Version: LoadzaVersions
Excel Version: LoadzaVersions

Re: Chores & Daylight Saving Time

Post by LoadzaGrunt »

After that you can ask whether it's possible to create a public view for data exports which is protected from the unsuspecting gaze of end users. Sad to say, I can't recall which of our august crew is the specialist on that topic, though it's caused enough grief for everyone from time to time.

Code: Select all

ViewCreate ( 'MyCube', '}temp' );
I'm not sure to what extent that would confuse the server but it isn't shown under views when 'Display Control Objects' is off .... YMMV
User avatar
BigDSter
Posts: 55
Joined: Thu May 15, 2008 8:02 am
OLAP Product: TM1
Version: 9.4.1
Excel Version: 2007
Location: Preston

Re: Chores & Daylight Saving Time

Post by BigDSter »

very very annoying and if I remember, one of the first problems I asked when we got TM1 4 years ago.

There is another option though now, which requires slightly less hair pulling (which is lucky as thanks to TM1 I don't have much left!)

d/ Use tm1choreexecute which is an applix tool that allows you to run chores from outside of TM1.

This means you can schedule a batch file from windows scheduler, which thanks to Microsoft (who would have thought they would do something normal) actually schedules at the time you schedule something for ... well duh :)

Anyway, we have quite a few of these now and they save an awful lot of time twice a year, as well as being a damn sight more flexible to schedule than chores.

Format generally for us is

c:
cd\
cd "program files"
cd applix
cd bin
tm1choreexecute.exe hostname servername admin password "Chore name"

Hope this helps.
David Newton
Burtons Foods
User avatar
jim wood
Site Admin
Posts: 3951
Joined: Wed May 14, 2008 1:51 pm
OLAP Product: TM1
Version: PA 2.0.7
Excel Version: Office 365
Location: 37 East 18th Street New York
Contact:

Re: Chores & Daylight Saving Time

Post by jim wood »

Not this old chestnut again. All I did was bare in mind what is the earliset that the schedules can run, then set them to that time when the clocks were back. It means that my log files are one hour out fro 6 months but it also means my schedules always complete sucessfully,

Jim.
Struggling through the quagmire of life to reach the other side of who knows where.
Shop at Amazon
Jimbo PC Builds on YouTube
OS: Mac OS 11 PA Version: 2.0.7
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: Chores & Daylight Saving Time

Post by Alan Kirk »

jim wood wrote:Not this old chestnut again. All I did was bare in mind what is the earliset that the schedules can run, then set them to that time when the clocks were back. It means that my log files are one hour out fro 6 months but it also means my schedules always complete sucessfully,
It has nothing to do with your log files. YOUR log files are in agreement with local time for 6 months of the year by virtue of the fact that you just happen to be sitting in a timezone which, for that 6 months, coincides with UTC. For everyone in other timezones, especially for those of us either either 10 or 11 hours away depending on season, our log files are "out" for the entire year.

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.

The log files have nothing to do with the chore scheduling, however.

I for one don't have the luxury of setting chores to the "earliest {they} can run" since the source files from other systems always arrive at certain LOCAL times, and the users are expecting to see certain data at certain LOCAL times. So if I set the chores to the earliest they can run, I either end up running it at a time when the source files aren't there yet, or I have users who for some odd reason seem disinclined to accept the explanation "oh wait an hour, it'll show up eventually", depending on season.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Chores & Daylight Saving Time

Post by paulsimon »

Hi

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

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.

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.

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.

Regards


Paul Simon
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: Chores & Daylight Saving Time

Post by Alan Kirk »

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.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
User avatar
jim wood
Site Admin
Posts: 3951
Joined: Wed May 14, 2008 1:51 pm
OLAP Product: TM1
Version: PA 2.0.7
Excel Version: Office 365
Location: 37 East 18th Street New York
Contact:

Re: Chores & Daylight Saving Time

Post by jim wood »

You could do the other thing we have done to get around the whole thing. We have shceduled our load process (and some data translation) through SQL. This has given us greater flexibility if files are not produced on time. It also means we have no scheduling issues. On top of that I get a nice email to my mobile to let me know if things have gone well (Or not),

Jim.
Struggling through the quagmire of life to reach the other side of who knows where.
Shop at Amazon
Jimbo PC Builds on YouTube
OS: Mac OS 11 PA Version: 2.0.7
User avatar
Steve Rowe
Site Admin
Posts: 2407
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: TM1 v6,v7,v8,v9,v10,v11+PAW
Excel Version: Nearly all of them

Re: Chores & Daylight Saving Time

Post by Steve Rowe »

Just a side point Alan, I think the two time fields in the log file record the start and finish of the operation, of course 99% of time this is the same thing. Sometimes though they will be differ by 1 tick. It's a pretty redundant piece of information though and recording the change in local and UTC would make more sense.
Cheers,
Technical Director
www.infocat.co.uk
User avatar
Steve Vincent
Site Admin
Posts: 1054
Joined: Mon May 12, 2008 8:33 am
OLAP Product: TM1
Version: 10.2.2 FP1
Excel Version: 2010
Location: UK

Re: Chores & Daylight Saving Time

Post by Steve Vincent »

Alan Kirk wrote:
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.
I hereby submit this here linkaroo > http://forums.olapforums.com/viewtopic.php?f=18&t=256

Now if IBM could be arsed to pick up the phone and sort out my access to their Insight! replacement i'd be able to check up on it. From memory they did replicate the issue and confirm it was "a 9.1 release" that it got solved in, but they couldn't track down which one. I do use this method for security cubes because they only have 2 dimensions and it doesn't seem to have any issues with them, but "normal" cubes it tends to screw up and crash the server.
If this were a dictatorship, it would be a heck of a lot easier, just so long as I'm the dictator.
Production: Planning Analytics 64 bit 2.0.5, Windows 2016 Server. Excel 2016, IE11 for t'internet
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: Chores & Daylight Saving Time

Post by Alan Kirk »

jim wood wrote:You could do the other thing we have done to get around the whole thing. We have shceduled our load process (and some data translation) through SQL. This has given us greater flexibility if files are not produced on time. It also means we have no scheduling issues. On top of that I get a nice email to my mobile to let me know if things have gone well (Or not),
WE can't, but it's a good idea for those who can do a "pull" process. (We do with our normal ledger feeds.) However some of our feeds rely on people having done certain tasks (adjustments, rebate inputs and so on) which are therefore tied to their local working hours. The huge honking great mainframe then does its thing but even if it were possible for TM1 to query the data tables it would take so long that it would lock up the server for ages, which is why we have to wait for the files to be generated from it. Everything takes a known amount of time, and always gets delivered on time, but the times are tied to the hours that people work.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: Chores & Daylight Saving Time

Post by Alan Kirk »

Steve Rowe wrote:Just a side point Alan, I think the two time fields in the log file record the start and finish of the operation, of course 99% of time this is the same thing. Sometimes though they will be differ by 1 tick. It's a pretty redundant piece of information though and recording the change in local and UTC would make more sense.
Cheers,
Given the column headings though, I think that may be a coincidence; it makes sense to track the start and end times of say a TI process, or the loading of a cube or what have you as the Server Log does, but punching a value into a cell is usually an infinitesimally short process and there would be no point in recording a start and end time. (Not, of course, that Iboglix has never implemented something that's a waste of time so I wouldn't discount the theory entirely...) I suspect that what's happening when you see that is that it's generating the timestamp for the two columns separately and that the second one just happens to be after the tick. But again, that's just a guess.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: Chores & Daylight Saving Time

Post by Alan Kirk »

Steve Vincent wrote:
Alan Kirk wrote: 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: 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.
I hereby submit this here linkaroo > http://forums.olapforums.com/viewtopic.php?f=18&t=256
AHA! Yes, I had read that one in the distant past, but now I know why it didn't trigger my synapses and why I haven't been able to reproduce it; I knew that as the "reordered dimensions" view bug, and we don't got no cubes with reordered dimensions. The greatest amount of memory I've ever been able to save is about 1.2% and it wasn't worth the potential hassle.
Steve Vincent wrote:Now if IBM could be arsed to pick up the phone and sort out my access to their Insight! replacement i'd be able to check up on it.
"Your call is important to us..."

The closest thing I can find to this in the Release Notes (and yes I grant that this ain't saying much given that finding fixes in the release notes is a hit or miss affair) is in the ones for 9.0 SP2:
286498 In TM1 versions 8.3.3 and 8.4.1, using View Extract to select and query elements in a view returned inaccurate results when run against a cube that contained reordered dimensions. This problem is fixed in TM1 9.0 SP2.
However given that you're on SP3 I'd imagine that the fix was still in that, assuming that it was in fact the bug causing your problem and assuming that it didn't become a regression bug in SP3.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
User avatar
Steve Vincent
Site Admin
Posts: 1054
Joined: Mon May 12, 2008 8:33 am
OLAP Product: TM1
Version: 10.2.2 FP1
Excel Version: 2010
Location: UK

Re: Chores & Daylight Saving Time

Post by Steve Vincent »

probably solved the view extract part of it, but still had the issue on the TI view create bit. might try my luck and ring them again later today, depends how the rest of my day goes :lol:
If this were a dictatorship, it would be a heck of a lot easier, just so long as I'm the dictator.
Production: Planning Analytics 64 bit 2.0.5, Windows 2016 Server. Excel 2016, IE11 for t'internet
Post Reply