Storing results of formulas in qvd files ctd.

[datanibbler]

Hi,

I just found out how to store the results of formulas (from one document) in qvd files for upload in another document. That works just fine when there is just one underlying table - I can do a RESIDENT LOAD.

There is, however, a difficulty: I haven't yet found a way to access the results of a formula other than by recalculating it. That means I cannot actually store the result, but I have to type the entire formula in the script.

Now, the formula of one diagram I'm just trying to store back into a qvd uses fields from five or six tables from the data_model.

Is there any easier way than using several RESIDENT LOADs and JOINs to reconstruct that part of the data_model that I need and pack all the fields in one table?

I tried just copying the formula to the script, but QlikView didn't like it. I guess set_analysis is not possible in the script. I'll try replacing all the set_identifiers by WHERE clauses.

Can anyone help me doing this?

Thanks a lot!

Best regards,

DataNibbler

[swuehl]

Maybe I haven't fully understood what you are trying to achieve, do you want to export the contents of e.g. a straight table chart that you've created in the frontend to a file?

If so, right click on the chart and use Export... where you can export your table data into a file using several formats, like Excel, txt, or qvd.

[datanibbler]

Hi swuehl,

no, that's not what I want to do. That would be an alternative to have the result data of a specific diagram, but it cannot be run automatically, one has to open the document to do that manually.

Instead, I want to use JOINs to gather all the fields one diagram uses into one table, replacing all set_identifiers and other filters used by the diagram by WHERE clauses in the LOAD and then use a STORE command to save it as a result_qvd.

In another document (the overarching management-dashboard), I then load just this qvd and I can display the core message of one diagram.

I guess there is no easier way, I have to combine all the fields necessary into one table using so many JOINs or MAPs. That means an enormous amount of trial-and-error as JOINs can be quite tricky, but I guess it's possible.

Thanks for helping anyway!

Best regards,

DataNibbler