QV11.20SR5: Direct discovery shown no new lines

[Anonymous]

Hello!

I just send the following case to QT Support! May someone has some more insights and can help me here? If Direct discovery does not retrieve lines that where added in the database since the last .qvw-Reload, I don't see many scenarios where I can use it in a meaninful way...

In QV11.20IR I was able to use Direct Discovery to show new datarows that arrive in the ERP system. The scenario would be that Direct Discovery can show newly arrived orders, without the need to reload the whole .qvw.

This worked fine as documented in this YOUTUBE Video: http://www.youtube.com/watch?v=bLToINb6Y_A

In QV11.20SR5 (new implementation of DataDiscovery) this scenario no longer works. I'm aware of the knowledge base article "Direct Discovery: New data in database not shown in QlikView application" (see attached screenshot).

As DynamicUpdate(Realtimeserver) is not available in QVSCluster, and DataDiscovery is not able to show new lines is there any supported way to fulfill the described scenario?

Why did you remove the functionality that was available in QV11.20IR?

[Anonymous]

I uploaded a Video that demonstrates my issue (QT  Support Case 238176).

See www.heldendaten.eu/blog/Case_ 00238176_Video.zip

Below you can see some screenshots that describe the most important steps in the video to reproduce the issue:

Second 5 of the Video

- We have a View v_Anfragenubersicht_TEST_DT that contains a single AUFTRAGNR 1514818, this table is queried by Direct Discovery. Cache = 3 seconds
-  The video will add a second AUFTRAGNR 1514817 to this view;
- In the "normal" QlikView table "QV_02_Anfragenubersicht_TEST" you can see that in Field "A" both values 1514818 and 1514718 already exist. See yellow box for script details

Second 31

AUFTRAG 1514817 is updated and therefore added to the DIRECT DISCOVERY View v_Anfragenubersicht_TEST_DT

 

Second 36

- Click Clear in QV
- Direct Discovery does not show the new Entry 1514817, even the Cache (3 Seconds should have expired by now)

Second 48

- SELECT some Values (includig 1514817 and 1514818) in Listbox, suddenly 1514817 shows up in Straight Table!

 

Second 53

- Clear Selection
- 1514817 disappears from Straight table! Why? 3 second Cache is definitely expired by now

Second 73

- Click Clear
- SQL Profiler shows that correct Query is executed against the database view; will return 1514817 and 1514818
--> as I click Clear multiple times the query is executed every time --> so it seems my 3 second Cache Setting is respected correctly by QlikView.

[#3]

Hello RVA_heldendaten,

I think first you have to understand how QlikView uses Direct Discovery to access relational data. Briefly:

• This is done by building a SQL query based on the selections values you have in QlikView. This is done automatically by QlikView.
• These selection values are filled from the memory values loaded during the document reload, in the fields you selected as DIMENSION. This values are used to maintain the associative logic (green, white, grey), even when some data is not in memory.
• If you add new records to your relational datasource you will see them, except if they have different DIMENSION values, not selected while the memory reload, and thus not addressable by QlikView.

     If this exception is your case, it is not because a bug but because Direct Discovery works this way, providing associative logic to non in-memory data. Maybe you could adapt your data model to show new records with this in mind.

     Other possible reason could be because of the cache. QlikView by default caches also the SQL query results to avoid over querying relational datasources. You can change the cache latency time with the DirectCacheSeconds system variable. (For table boxes, the data is always queried).

     About other meaningful scenarios, I have to say that although Direct Discovery can be used for real time access, its main purpose is conduct associative analysis on big data sources without limitations, and enables users to combine that big data with data stored in memory from any other data source (this mix of in-memory and bigdata is really, really amazing). This way you could access detail data, historical data, etc., up to the more detailed record without having to load in memory billions and billions of data.

Hope this helps,

JG

[Anonymous]

Hello!

As you can see in screenshot "Second 3":

- Cache is set to 3 seconds; so this can't be a reason

- The value 1514817 already exists in the "normal, associative" Listbox "A"  (which is the same as key field AUFTRAGNR [you can see the script in the yellow box)

-->still Direct Discovery does not retrieve the values for 1514817 at "Second 36"

To me this is a bug.

[Anonymous · Accepted solution]

The reported issue ID 67824 has been confirmed by R&D as a bug.