Upon importing some old survey archives (.lsa) into version 2.50+, I ran into a couple of instances where the token table wouldn't display in 2.50+ after the import. No import error was reported. The token header row would display, but no contents loaded. However, token records were confirmed as present in the token summary.

It turned out that each of these token tables contained a few records where the completed field contained a trailing colon such as "2014-09-11 17:05:" instead of "2014-09-11 17:05". After deleting these trailing colons, each of these token tables then displayed properly. I did so within 2.06lts, then created a new archive, then re-imported it into version 2.50+, though it would seem to follow that correcting them directly in the database ought to have the same result.

I'm not sure how those trailing colons got there in the first place. All of the instance of this that I ran into were submission back in July, August, or September of 2014.

Anyway, I am am simply posting this here in case anyone else happens to run into this.

Thanks for mentioning.

Not sure if it is worth to record a bug report, maybe there is a solution to avoid this completely.

I think a bug report might be premature until enough others begin running into it.

I suspect the same behavior might be experienced if I had upgraded an older version of limesurvey to 2.50+ before editing those token records, rather than importing the archive. But I didn't actually try that.

Thnik there are 2 potential bug (maybe 3)

1. Even with invalid value : token list must be shown : if you set manually 2014-09-11 17:05: in token table : the token table must be shown
2. When import : i'm not sure we need to fix or no this value : the bug must be reported like this "invalid value are not filtered/validated" decision can be lto leave it like this
3. And finally the export lsa/import lsa are not comaptible: did the : exist in 2.06 DB ?

@DennisChenu, yes the extra colon was in my 2.06 DB, with the token table loading fine there with it there.

Another thought -- is "check data integrity" meant to catch things like this as well?

Then
1 must be fixed : deprecated in 2.50

For check data integrity : maybe another bug report. Don't know

I submitted a bug report after testing this on a manual edit of a token record directly in 2.50+ (instead of importing an archive). See bugs.limesurvey.org/view.php?id=11177