Cleaning up old variables

[datanibbler]

Hi,

I know the tool "DocumentAnalyzer". We have it, though probably not the newest version. For fields, there is a built-in function to generate the "DROP FIELD" statements for all unused fields.

=> is there an alike functionality - or is there some other possibility - to generate the necessary LET statements to reset all variables in the app?

(as QlikView keeps all variables when closing, it might well be that at some point a variable was changed and its name also, and so the old, outdated variable is still around which can cause malfunctions to not be immediately detected ...

Thanks a lot!

Best regards,

DataNibbler

[datanibbler]

Hi Marcus,

aha - so I cannot delete the variables which are not reset in the load_script, but are intended for use on the GUI.

Well, then I'm afraid it's back to the Variable_overview - or I can try that macro. Let's see ...

Thanks a lot!

Best regards,

DataNibbler

[datanibbler]

That one works fine!

After executing that macro, all the variables are altogether gone and my app is clean just like I wanted it - all the necessary variables will be newly generated in the next run of the script.

Thanks a lot!

Best regards,

DataNibbler

[Peter_Cammaert]

The theory it that all variables that have been created by way of the Add button in Settings->Variable Overview cannot be deleted by setting them to NULL() or nothing in the script. In the Load script, you can change their value but you cannot make them disappear.

But Marcus' macro solution will work as well. And you have to run it only once, so afterwards you can remove the macro from your document  or keep it hidden as a secret weapon for any future situation where some nitwit forgot to cleanup his variable mess

Peter

[datanibbler]

Hi Peter,

yes, that's exactly what I intend to do - keep the code of the macro in a special folder for one-off use

(spring cleaning 😉

in any app.

Or - you wouldn't know how it might be possible to automatically run that macro at the end of the script run? Then I'd just have to remove from the code the msgbox, and that macro would look after cleaning up all newly created variables every time - every script generates or imports all necessary variables in every script run, so that wouldn't hurt, and some degree of cleanliness is always important in development work ...

Thanks a lot!

[Peter_Cammaert]

Well, I wouldn't run this macro at the end of your script but at the start, for a simple reason: you never know when some script-defined variable suddenly has to survive the script run (like vYearToday or some configuration variable that is lifted from a DB table). And IMHO it's better to start with a clean slate. In the end, your scripts should be extended (let's say gradually) with the appropriate cleanup SET statements.

IIRC macro's can be called from inside your script by converting them into a function and using them in a LOAD statement. A very simple one in your case.

Maybe marcus_sommer can shed some light on how to best approach this? He's way more experienced with macros than I am...

Best,

Peter

[datanibbler]

Hi Peter,

you're right of course. At the end of the script would be a bad place since variables are often intended for front_end_use. At the start is better.

Unfortunately, I have never worked with UDFs in scripts. But maybe Marcus can lend me a hand here?

Also, the handling of macros in QlikView seems to be a bit nitpicky: I just added a comment (using the appropriate sign) in the macro which I wrote into a txt file for storing - and when I pasted it back into a QlikView_app (I always start by creating a button, then add the action of running a macro and then I click on "edit"), when I clicked on "OK", I got the message that the macro is not functional ... maybe because the comment was outside the keyword SUB?

Strangely, when I deleted it, it still didn't work ... I then copied it from the post once more and it worked.

[Gysbert_Wassenaar]

I think a better approach would be to do your spring cleaning once and then only create variables in the script so you can also clean up those you don't need anymore at the end of the script. That means that the variables that should be used in the front end should also be created in the script.

You could use an excel or text file that contains the variables and the values the should have and an indicator for removal. You can then have a fairly simple routine to create all the variables at the beginning of the script and another routine to remove variables at the end of the script using the same variable definition file.

[datanibbler]

Hi Gysbert,

excellent idea!

I have to try that out. Right now, though, many of the variables - in the primary data_loading_scripts which I'm currently working - come from txt files which are INCLUDEd in the script - all the file_path_variables. There is one txt file per area, holding all the path_variables for that area, which keeps it all nice and organized and faster to search.

However, it would be possible to structure that in another way.

I know that method, I have used it somewhere, I'm confident I can piece that together again. That would certainly be the easiest way of keeping the apps nice and clean by automatically removing all variables which have been created in the script - the other part (creating ALL variables ONLY in the script) is more difficult - technically well feasible, but difficult to ensure if apps are being created by more than one person 😉 Might be doable with a well-trained and kind of disciplined team, but I am realistic in that respect, which is pessimistic enough 😉

[Peter_Cammaert]

A good compromise (simpler because you don't need to offload every variable creation to a management Excel) to start with would be to use Gysbert's suggestion but only the last part: create an Excel that lists all variables by document name that should survive a script run. Add a macro call to the end of your script (yes we're back to the end...) that drops every variable that isn't listed in this management excel. May have the right balance between tightening the developer net and not introducing too many administration chores in external configuration files.

Peter

[datanibbler]

Hi Peter,

we're getting there. Whether I run the macro at the end of the script for only a part of the variables or at the beginning for all of them, before again creating all the needed variables, would not make much of a difference.

Only, I need to know how to build a UDF to run that macro from the script to begin with.

Well, if I have the time, I will try it out. Only - well, time is always an issue. Everyone wants stuff, all to be finished yesterday, and the very minute you sit down and start doing it, the next one comes around with the same wishes ... I guess you know that.

Thanks a lot!