Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

qlikview publisher task dates set 01/01/0001 00:00:00

Hi,

Since yesterday qlikview publisher dates are all 01/01/0001 00:00:00T

Tried to restart the services it didn't help. I looked in the Programdata folders. all the dates in the xml files and log files are correct. it just the console that is not displaying data correctly

example of task history

01/01/0001 00:00:00Succeeded21 min 16 sec
01/01/0001 00:00:00Succeeded16 min 28 sec
01/01/0001 00:00:00Succeeded25 min 4 sec
01/01/0001 00:00:00Succeeded13 min 13 sec
01/01/0001 00:00:00Succeeded23 min 47 sec
01/01/0001 00:00:00Succeeded20 min 11 sec
01/01/0001 00:00:00Succeeded24 min 23 sec

did anyone encountered this issue?

6 Replies
Not applicable
Author

Some more informaiton it is a display issue when the qms acess the qds . see entry from management log:

13/07/2012 18:49:45.6753059ErrorSystem.Exception: QDS did not respond to request.

Last exception (for http://srvcrm86:4720/QDS/Service): The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://ws.qliktech.com/QDS/11/:GetTaskLogResult. The InnerException message was 'There was an error deserializing the object of type System.Collections.Generic.List`1[[SolutionGlobal.Logging.LogfileEntry, SolutionGlobal, Version=11.0.11282.0, Culture=neutral, PublicKeyToken=null]]. String was not recognized as a valid DateTime.'.  Please see InnerException for more details.

   at PIX.Services.ClientSupport.ClusterBase`1.Invoke[TR](CallType callType, Func`2 func, List`1 allResults, QlikMethodBehavior methodBehavior)

   at PIX.Services.ClientSupport.ClusterBase`1.Invoke(CallType callType, Func`2 func, QlikMethodBehavior methodBehavior)

   at PIX.Services.ClientSupport.QDSClientImpl.GetTaskLog(Guid taskId, Guid logId, Int32 maxRecords)

   at QMSBackendCore.Communication.DistributionService.GetTaskLog(DistributionServiceResource qdsResource, Guid taskID, Guid logID, Int32 maxRecords)

Not applicable
Author

I have the same issue - Did you resolve this?

Bill_Britt
Former Employee
Former Employee

Hi Thomas,

Is this a cluster system? If so, check to make sure the date format and time zone is the same on all servers.

Bill

Bill - Principal Technical Support Engineer at Qlik
To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.
Not applicable
Author

Hello Bill,

No its not a cluster system - It has also worked before. So i think its a bit strange - i also cannot see my log under status. It says its too big and that i should correct MaxLogRecords

Not applicable
Author

Thomas, Yakir,

did you found the solution?

I've a similar issue, described here: QMC 12/24 timeformat

Any hints?

Thank you guys

/olli

Anonymous
Not applicable
Author

Hi Yakir,

The issue has been caused by the Regional Settings of the QDS being different to the QMS previously. The date appears as 01/01/0001 because the QMS cannot understand the date format in the tasklog.txt file produced by the QDS. This can be confirmed by changing the logging in the QMC to DEBUG. When I did this I saw the following error:

System.Collections.Generic.List`1[[SolutionGlobal.Logging.LogfileEntry, SolutionGlobal, Version=11.20.12589.0, Culture=neutral, PublicKeyToken=null]]. String was not recognized as a valid DateTime. ---> System.FormatException: String was not recognized as a valid DateTime.

The QDS writes the date and timestamp to the tasklog based on its Regional Settings. Once the Regional Settings matched that of the QMS, we restarted the QDS and QMS services. Tasks dates and times were readable from then on.


If this is not the cause, setting to DEBUG  in the QMC will shed more light on why it is failing to read the date and time of task. Please remember to turn off DEBUG logging when no longer needed as the log files become much larger due to more information being recorded.


I hope this helps.