one issue that I have been coming back to every now and then is creating Backups on a regular basis.
There's no question that it's necessary to do so in a professional environment.
The issue is, we have an official routine in the company, but that is not very reliable and it's just too slow - it takes 3d to have a file re-created, and then it is not absolutely certain that it works ... so it's necessary to have something else in place, but I cannot count on the help of our official IT_department, I can't ask them "help me build something because your solution is too slow" - they (the local IT) might do it - but they cannot, it's global and they are not allowed to circumvent global standards.
So - what I would like - maybe something like that is available already, I don't have the spare time to build it - is a tool that just
- opens every app lying in a specific directory (we have a Backup directory already, I create a folder with a datestamp there once in a while and just copy the apps over)
- Runs the app and deletes all the data
- closes it
=> Thinking about it, is it not that when reloading any app, qlikView first deletes all the data before loading it again? So I could just put an EXIT command, depending on the value of a variable (with an IF THEN ENDIF) into every script. That way, I'd still have to open up and run every app, but I could do that.
I could make the value of the variable - or the loading of the qvs file with the variable - dependent on the directory, so only the apps that are already in the backup_directory would load it.
<=> Would that work with a BINARY? Many of our apps have a BINARY command to load a big DataModel - we have a three-tier structure. The BINARY, acc. to the help_file, has to be the very first command - so how can I put that EXIT construction before it?
I just made my ready developed and tested code into a document.
I think it is easier than going the "File -> reduce data -> delete values" way, though it does take the extra time to run the BINARY - in the apps where there is one - and it does produce .log files that you should delete again - though they are very small.
yes, that should also work - I just didn't know about that function - I tried FILEDIR() and all those, but I didn't find one that helped, so I came up with this.
