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

[Gysbert_Wassenaar]

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 😉

Make it part of the process. An app cannot be put into production unless all the variables have been added to the variables definition file. Just another thing on the checklist. For development it's ok to create variables with the UI, but to make the app production ready the variables must be moved to the variables definition file.

[datanibbler]

Part of the process - yeah, sure 😉

Sorry, but I have quite some, mostly negative, experience with processes.

The only effective way I know of enforcing processes is when non-compliance with a process has immediate and ideally automatic consequences, without the need for anyone to do anything to effect the consequences - because as soon as someone (other than yourself) is involved, you have the issue of friendships, colleagues and all that good_ole_boy stuff 😉 What's missing here to fix that is a system of employee-motivation and incentives. There are things like easter-brunch and a christmas-party and such - not bad, but there's nothing directly linked to performance or compliance to processes because as soon as you try to introduce that in Germany, the "Betriebsrat" steps in ...

For that reason, I think putting the macro at the start of a script and just removing all variables from an app is the better approach - because if someone had the idea of creating a variable in the UI only and not even leaving some comment in the script - which is written down in our "developers_guideline", it just won't work and that person will just have to do it again and ideally learn from the mistake ...

But okay - all that is purely theoretic for now, I don't have a team of developers to organize, I have just myself which makes the issue of standardization somewhat easier 😉

[Peter_Cammaert]

There are two definitions for UDFs: one uses variables and $-sign expansion, the other one uses real macro code in a FUNCTION definition. That's the one to use.

Some useful links:

Re: how to create a user defined function?

Using Macro functions in Script

[marcus_sommer]

Hi DataNibbler,

I'm with you that's quite hard to create real processes from the conceptualization from an application to their development, testing, deployment and finally the live-administration if you are a lone fighter - it's even a huge challange if there are a big team of experienced people which has already worked within such a controlled environment.

Some years ago I started such centralized standardization on a database not only for variables else many other things like expressions, fields, tables, comments, tags, sheetobjects and so on - but I ended it soon as I realized how many efforts was needed and that I hadn't enough time for it.

Therefore some more practically approach was needed. In my case I use a preparing script-tab in which I load several include-variables with paths, fileformats, other variables and various other things like section access, sub/load-routines and so on and the last script-tab is called cleaning and cleaned everything again (also with include-files unless the application specific variables, fields, tables which I put there manually).

Also I use a 3-tier data architecture which prevents that script-variables comes into the report-layer. Further I use variables only if I really need them and have only a few application where I need the scrolling within the variable-overview. Quite often I see cases in which for today and yesterday and so on and for nearly each expression a variable exists but in my opinion will be the handling not easier with them rather the opposite is the case.

To be more specific to your case I wouldn't use this macro regular - only if it needed. Helpful could be to use a naming convention for creating the variables like vVar or eExp maybe with s_Var for script-variables which could be checked within the macro-loop.

I hope it's more explanatory then confusing you.

- Marcus

[datanibbler]

Hi Marcus,

yep, I understand. Well, of course it's some work to establish a process and standards - but it's somewhat easier to stick to these yourself than to ensure a team of co-workers do so in every instance ...

I also have a template_app which can be used to create new apps of any kind, with some script_tabs which can always be used and a lot of INCLUDE files which hold variables and some common pieces of code - and also with templates for objects of different kinds as there are also some things which you should keep in mind when creating objects - like writing something into the caption_line even when it's not supposed to be displayed - when you want to search for something in the document_properties, that makes it much easier to identify stuff.

I'm not sure yet about whether to use this macro regularly in a script or not - as of now, it seems sensible to do so - that way you can keep an app clean and ensure that variables are really only created in the script - because variables created on the GUI will just be gone. There are methods to also create the "GUI_variables" in the script, so that should be doable. A naming convention makes sense, also I already have one.

Best regards,

DataNibbler