Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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).
The only thing that comes to mind based upon the new posts is the following. If user A opens the QVW and then user B also opens the same QVW, makes changes and then saves things, user A will get a prompt etc., and I believe they can override the changes made by B at that point such that if they made no changes, the app would revert back to original state... I did not test this, but I seem to recall this being possible, so I wanted to toss it out there. This is where it can be good to have staging process such that folks have to check-out/in etc. such that you do not have two folks working on the same QVW etc. This is one potential possibility I think. Marcus is correct too as far as I know, we are using all Windows APIs related to the file processes... The only other thing of which I can think is you may have some software that monitors the file store and is looking for changes, and if it sees any, it is reverting things back thinking those changes are bad or not allowed, would likely be anti-virus related etc...
Regards,
Brett
Hi @Brett_Bleess @marcus_sommer
Is user setting "save compression" (High,Low,None) also using windows library? just throwing it as it seems to be more of Qlik feature than Windows feature. I don't know if it makes any difference or not.
regardless - like i said, I am the one and only one person working on the file and it happend to me 3 times yesterday that it rejected changes.
From now on I will record video every time i try to save document hoping that this will catch the issue. I will also straight away look at windows logs searching for cues
regards
Same here. We are working with four developers here, and there's never someone working in the same qvw file (separated disciplines) at the same moment.
I don't think it's related to the Win API, though. It's reverting to the previous load situation instantly, not doing any file saving whatsoever. And instantly does mean INSTANTLY.
Lech, if you do manage to get a video, that would be great.
Hey guys, the Compression setting is actually us as far as I am aware, we are doing that compression prior to sending the file to be written to disk, the same goes on open, we have to pull things from disk, then do the decompression... One thing you could try on the problematic app(s), would be to set the compression to none, that is going to make the disk size larger, but you could see if that impacts things or not...
Hans, in your case, that would make me think you have some utility in your environment that is getting in the way of things and preventing us from saving the file, if ProcMon is not showing that utility though, I am not sure how to go about trying to figure that out, you can manually check to be sure anti-virus exclusions etc. are in place on our directories... Sorry I do not have anything better for you at the moment. Shout if you have more questions.
Oh, the only other thing, check your client version and be sure that matches the version the QVServer is running, if those to not match and are way off, major release difference, that can be problematic too, just wanted to toss it out there too.
Regards,
Brett
Me and some colleagues have experienced the same thing (in two different customer environments). Very annoying!
We tried activating the 'Use backup' and that seemed to help.