QlikView rejects changes after saving work

[hansdevr]

Do any of you have this problem?

Lately (QlikView V.12) rejects all changes to my dashboard, both in the visuals as in the load script. It occurs right after a save, or even just before saving!

Very frustrating, as you lose all work you have done in the last few hours!

It doesn't happen very often, just now and then, but I get tired pressing Ctrl+S 300 times per hour....

It happens both locally and while working with QlikView on RDS (from home).

[hansdevr · Accepted solution]

Hi Marcus, I agree.  A collegue had the very same problem more than a year ago (I had a hard time believing him..), and this was far before any major update.

I'll let it rest for now. Everyone a warm thank you for your suggestions.

[Brett_Bleess]

Hey guys, may be a stupid suggestion, but I wanted to throw it out there, you have the option of setting autosave in the Desktop client under Settings\User Preferences and the Save tab, so I think that would do two things here, keep things saved as you go, and alert you if someone else may have gotten into the app as if the autosave fails at some point, you then know something has happened on the disk copy.  You should be able to do a SaveAs in this situation so you do not lose your work as well, the trick is having to compare files at that point to see if you can just overwrite or if someone did change something etc.  Hopefully this may help a bit.

Regards,
Brett

[Josh_Berg_Support]

Would you be able to post a video of this behavior?  What version of Qlikview Desktop are you using?  Do any of your colleagues experience this issue on their machines?

Thanks,
Josh

Qlik Support

[Jagsfan82]

---

@hansdevr wrote:

Hi Marcus,

I rather like your suggestion to create copies through user settings. Although: This morning QV reverted to an older situation WITHOUT saving or (re)loading, so I still suspect the cause to be QV...

I just saw a short blink on the screen and I got the old situation back (from an hour before).

---

This just happened to me and I'm pretty annoyed by it.  And the system backup got updated to the same state.  

[hansdevr]

We just have upgraded to enterprise version 12, april 2019.

I'm sorry to say we just experienced the same problem twice with this new version, although we now have detected that the problem occurs mostly when using Ctrl+S. When clicking the diskette icon, there is no problem with saving your work.

It's not possible to record a video of it, because it doesn't ALWAYS happen. But we do know now, that when using Ctrl+S it happens most frequently.

We do think this is a bug.

[marcus_sommer]

Like above indicated I doubt that's really related to Qlik because saving a file through the OS within the file-storage (Qlik like the most other tools doesn't do it directly else they use windows *.dll's and/or transfer these tasks to the OS) means that the file is stored at this point.

If you could exclude that any other user has opened the file in parallel and stored it again after you stored your changes - the reason for the rejects must be your storage (it might be only cached and not physically stored and if the queque of storing-tasks is disrupt in any way it might fail - I know many of such cases from our excel users which close their laptop before the saving is finished and often it cut the network-connection, also the quarantine feature of any security tools could cause trouble ... probably there are far more possibilities which might prevent a successful storing). And then of course could there be various measures applied (with external tools and from the OS which restore the filesystem or parts of it to certain moment).

- Marcus

[marcus_sommer]

Interesting - but doesn't come then a popup by closing the application that there are unsaved changes?

Beside this it might be related to your (corrupt) keyboard and/or there are any keys configurred in an unusual way (maybe only related if a certain tool runs in parallel). But like above mentioned closing the application unsaved should return a warning message.

- Marcus

[Lech_Miszkiewicz]

I am on November 2017 SR5 ( 12.20.20600.0). I have however experienced it before on other versions too...

It is extremely annoying behaviour which I have also experienced. I am the only person doing QlikView development and i noticed that this often happens when working with large documents ( 3+ GB). Autosave is not an option when working with such large documents as it slows everything down too much!!!

There is Symantec Endpoint Protection software installed (if it is important?). I am not using prj folders.

I have no idea what is causing it.

[hansdevr]

I have ruled out all situations earlier posters have mentioned that might cause the problem. Although using the diskette icon when saving helps, it still occurs every once in a while. In can confirm that larger documents do have a tendency to cause this problem more often than small.

It's bitterly annoying, because working for two hours in a document and then losing all changes is not only irritating, but it does also diminish your trust in the application. And I work with both a local install of QV and a network version through RDS. Same problem in both versions.

[marcus_sommer]

Again I must admit that's hard for me to believe that there is such a bug in QV - and that over several releases. AFAIK QV used only the standard windows libraries to access any files and to store them - also the functionality to display a * behind the filename in the window-title if there are any unsaved data is probably a windows feature. For me it seems rather unlikely that QV has changed here anything or that there is general problem with this approach. If so this kind of issues should happens more frequently and not only be related to QV else to other tools, too. Nevertheless it might be but then should Qlik be able to say if they touched anything which might be related to it.

Therefore I think the issue is more singular to some very special circumstances. This maybe your keyboards, keyboards-driver or any installed shortcut-tools which may prevent the correct working of ctrl + s and the other thought goes to the used network / storage - maybe it's too slow and/or any timeouts happens or the storage-task is queued and breaks sometime later …

- Marcus