Transfer objects and problem with auto calendar (Help!)
Hello, I am IT-product support specialist, I have never worked with Qlik Sense before. An employee in our department who worked in Qlik Sense quit and we transferred his developments to the storage of another employee. We use an internal server where all analytics from Qlik are stored. After the Qlik apps (dashboards) were transferred, they visually appeared for the new employee, the ODBC SQL connection in the code line was updated, but a problem with internal files (excel documents) arose. When trying to reload the documents, an error occurs, since auto-calendar is used. The only thing that helps is deleting or commenting the line DERIVE FIELDS FROM FIELDS [..]... . There are a lot of Qlik apps, is there any other solution to this problem, so as not to comment this line in each dashboard? As I understand it, the problem lies in the binding of auto-calendar to columns and a hidden protection mechanism is triggered, but I am not sure about this.
Also, after moving Qlik apps to the new user's folder, a second problem appeared. This user had several developments earlier, a couple of personal dashboards (new employee). Now, when publishing from a personal directory to a common one and then taking it back for revision, the links in the object are broken. This did not happen before, it only happened after moving Qlik apps from the old to the new employee. What could be the problem and what are the solutions?
For example I attached a block of code for the auto calendar
I don't know what's causing your issues - maybe the specified fields are missing or aren't interpreted as dates else as strings or similar stuff ...
Beside this I suggest to consider to replace this approach completely against a "real" master-calendar. The auto-calendar as feature is well-intended but only helpful within the simplest cases. As far as it comes to any advanced scenarios it's a big disadvantage because it's not sensible to repeat the calendar-creation in each application against the fact-data without having any simplifications with the declare/derive-statements (against normal script-measurements) or in applying advanced calendar-information like aggregations, accumulations, some flag-types and so on.
Better would be to create a single master-calendar for the entire environment and each application picked those fields and periods which are needed. Here a starting point to what is meant and might be possible:
