EDX in QlikView

[datanibbler]

Hi,

I know this has been here a number of times and people have posted a number of links to useful  blog_posts and examples. I will try. I have the requirement of using this because we don't have many Named_CALs left and I just learnt that a Document_CAL doesn't let the user reload the script from the GUI, which is a core function of my new app.

I just learnt from one of those documents that we might end up facing problems when several users use this functionality m.o.l. simultaneously. Originally, I created the app so as to minimize the risk of any user saving over the work done by another by limiting the time that the data actually remains in working memory. This won't work quite that way anymore now.

What I am not quite sure about is: Will this work in only one app or will I need many?
=> E.g.: I have the database_entry_mask that the user will have open. In that mask, there are several buttons which reload the script
     (the script is subdivided into blocks, but I could make those into one qvw each if necessary, never mind)

     => Will that work, the server reloading the script of the app that the user is currently viewing (or reloading a script in another app and
          then updating  the app that the user is currently viewing?

Thanks a lot!

Best regards,

DataNibbler

[jonathandienst]

This thing of yours seems to be getting more complicated as time goes by -- square pegs and round holes come to mind.

Something you will need to consider with EDX is that EDX raises an event at the server, and the server will decide how and when to service those events. You may also have multiple qvb.exe batches trying to update the data at the same time.

[Anonymous]

IMHO if the requirement is that end users need to see the very, very latest database data then this is an Operational requirement and not a BI / Analytical requirement.

As such I'd suggest that QlikView is not a good match for this requirement.

EDX reload from the GUI does work in a limited test scenario.  I have tried it though with multiple users and the server initiating reloads potentially simultaneously and encountered frequent errors.

[datanibbler]

Hi Jonathan,

you're right. It is getting more complicated. This factor - that reloading from the GUI is possible only with Named_CaLs - should have been one to consider at the outset, but I simply did not know. I assumed from what I had been told that it would be possible with a Document_CAL - but I don't want to rule out that I might have been told once and forgotten by now as we never had the necessity of reloading from the GUI up to now.

I have already noticed that the detour via the server will slow the whole thing down (and the EDX tasks will have to run with a high priority on the server).

So I think I'll split the whole thing:

- The people in the office who work with this a lot (thus there is a higher risk of their sessions overlapping) will get
   Named_CALs so they can use the much faster way, working   in the Client.

- ns The people on the shopfloor who are going to work on this only once a while (thus the risk of their sessiois
   overlapping is lower) will get the EDX solution and a Document_CAL.

[datanibbler]

Hi Bill,

I was aware of the fact from the start - I didn't know all the details, but I always did have the impression that using QlikView for this was not the ideal way to go.

The thing is, we have QlikView and we don't have any real database_tools - nor do we have (or knowingly have) anyone with knowledge in database_building or in SQL and such (I believe there are SQL building blocks for this to be found online). And getting the authorization to spend money is a difficult thing here 😉 - not that I work for free, but nobody considers the costs of existing personnel.

I just have to try and hope that the intervals between different shopfloor_people using that app will be big enough for the server to complete one reload_request before the next one comes in ...

I will also try to re-model my app so as to minimize the number of reloads needed:

Right now, the app has to reload for the first time right upon opening so it "knows" the authorizations of the user currently logged in (there are two different roles, with different sets of privileges (on fíelds) attached) and so one of two alternative sheets for data_input is displayed

=> I guess I'll split the app into two near_identical ones, one for the people in the office and one for the
      shopfloor_people. That way, the first reload will be unnecessary.

[datanibbler]

Hi,

I'm talking to the ones in charge. There would always be a risk of several people overlapping in their usage of the database if we were to implement the EDX solution. That is not really what we want, either 😉

Thus I will argue for spending a few thousand Euros for a few more Named_CALs to enable the users to work in the Client, which is much faster, thus reducing that risk.

Apropos: Can several people open the same app locally? I think they can, no? They should not save it at the same time and if one saves it while the other one has data in RAM, the later saver wins, that is clear - that's why I have designed the app so that at the moment one user hits "save", the most current data is actually loaded from the qvd once more, in case it has been edited in the meantime, one specific record is updated with data from InputBoxes and the table is immediately saved again.

I guess that, though it will not be perfect, using the app in the Client would still be the better of the alternative solutions, given that

- I have no experience using either Visual_Studio or APIs of any kind and

- I do have doubts whether the privileges that the shopfloor_users have on their PCs would be sufficient for this (though I don't yet know
    in detail exactly what they need to do, but we all have somewhat limited privileges)

[Gabriel]

Hi,

If users wish to see latest data frequently, I will suggest adjusting your task on QMC to reload may be every 30 min or 1 hr. Allowing user to kick off reload is some how not best option I think. I think reload should be centralized.

Just a thought

[datanibbler]

Hi Gabriel,

generally, I'm with you there. But in this particular case, having the server reload the app regularly is not an option. The users have to enter data that is to be saved in the qvd, not just view the data in the app.

That is why the reloading must be in the hands of the users.