Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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?
The reported issue ID 67824 has been confirmed by R&D as a bug.
Below you can see some screenshots that describe the most important steps in the video to reproduce the issue:
- 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
AUFTRAG 1514817 is updated and therefore added to the DIRECT DISCOVERY View v_Anfragenubersicht_TEST_DT
- Click Clear in QV
- Direct Discovery does not show the new Entry 1514817, even the Cache (3 Seconds should have expired by now)
- SELECT some Values (includig 1514817 and 1514818) in Listbox, suddenly 1514817 shows up in Straight Table!
- Clear Selection
- 1514817 disappears from Straight table! Why? 3 second Cache is definitely expired by now
- 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.
Hello RVA_heldendaten,
I think first you have to understand how QlikView uses Direct Discovery to access relational data. Briefly:
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
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.
The reported issue ID 67824 has been confirmed by R&D as a bug.