Qlik Community

QlikView Deployment

Discussion Board for collaboration related to QlikView Deployment.

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

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

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

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

I have the same issue - Did you resolve this?

Employee
Employee

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

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

Not applicable

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

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

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

Thomas, Yakir,

did you found the solution?

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

Any hints?

Thank you guys

/olli

srm
New Contributor II

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

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.

Community Browser