Hi
Has anyone any experience with SV’s In-Memory driver?
Trond
Yes, quite a few of us
Think of it as a TPS driver with the file stored in Memory.
It’s a nice alternative to a Global Queue because you get a threaded file buffer (i.e. an instance of the data) and the driver synchronizes access. You can use templates that work with files like Browse and File Drop that offer many features you don’t have with a LIST,FROM(Q) without code.
I use it to keep a copy of the chart of accounts file loaded in memory for much faster access. The file is filtered by user so can be slow to load across a network. It is accessed a lot and changes little.
There is some content on Clarion Mag on the IMDD. I think you can read the user guide on the SV website.
1 Like
I wish I bought the $399 bundle that included the Dynamic driver with the IMDD for an extra $144 versus $225 alone.
How does it display the contents in a List Box.
We are testing our new Virtual Queue Classes that display virtual queues and virtual data.
Is that how you display the contents…
I assume you mean the IMDD? It looks like a regular clarion file, so you just use it as such. I use it in one app on a regular browse to show the results from a call to an SQL stored procedure
1 Like
A VLBProc that could be used for all IMDD Files could be written
So that there is no need to create a queue and copy contents to the queue
Just so you can have a LIST,FROM(Q)
I don’t use the IMDD so I haven’t written it
But it should take just a few minutes to write
Here’s a nice head start
ClarionCommunity/ctVLB.inc at master · MarkGoldberg/ClarionCommunity (github.com)
ClarionCommunity/ctVLB.clw at master · MarkGoldberg/ClarionCommunity (github.com)
1 Like
post of example virtual column class removed.
I was just talking about a simple vlbproc that supports using an IMDD as if it were a queue.
As I think about it
One of the things that a vlbproc has is a .CalcChanges() method to determine if the source data has changed. With a queue we use the RTL command CHANGES(Q).
For a file I believe we will need to implement something on our own. Coincidentally I recently wrote a FileCallback that stores a dateTime of the most recent write. I called it LastWrites, well ctFCB_LastWrites anyway. I’m willing to make that available…
the class above supports firing 3 different scripting models allowing any type of support you like in your virtual VLBPROC.
Yes i see what you are suggesting. The principle is the same though as the model classes above support the type ClaDataType:VirtualDataItem which fires anything you can put in evaluate , or a full blow scripting model.
Your last write would indeed be required to reload the in memory files?
Sorry I wasn’t clear
in a VLBProc, there are special encoded “row” values. When ROW=-3 the VLBProc want’s to know if the data source has changed presumably so it can decide if the LIST control needs to re-fill itself from the data source
So, we’re not talking about refilling the IMDD File, but rather determining if there are updated contents which need to be shown in the LIST
And this should be a fast decision (not bogged down with complexity), because it gets asked a lot.
1 Like
The ctVLB Proc would store a LastFilled DateTime
.LastFilled would be set when asking for ROW=1, COL=1
Then the ctVLB.IsQChanged would simply compare SELF.LastFilled to the injected reference to the Glo:TableYada:LastWrites.DateTime
IOW – it’ll be fast
Cool. My comment was more directed to the stuff Steve posted.
yes mark . The class example i remove above handles the row and col reloads. Your original class was the one we modified to allows the super class to be developed.
it really does power up the virtual queues beyond the very simplistic examples in the help…
How are all the graphic stuff you have developed going. We have a project in sweden that needs some graphic expertise for display accelerometer data graphically.
im not a software engineer these are just tools that do stuff and we have stuff that needs doing.
I think it was JS who showed us a very fancy color picker using a special VLB developed?
noting the colordialog in CLA GPF if a manifest is not included in the exe.
lots of off topic stuff here…
This may have run it’s course; but, I thought I would add my two cents worth. I work at a window production company and we have to schedule several thousand windows for production a day. The original code used a queue and directly manipulate the records in an Oracle database. This was slow and caused a lot database activity; and, rolling back was an issue if there were errors in the production process.
We corrected this by replacing the queues with the IMDD driver. We added stored procedures that copied the data to be processed into a temporary table, which we loaded into a IMDD table. The speed was very attractive and the ease of displaying the data was like using a regular file/table. You can index the heck out of them and you don’t have to keep resorting it to display in a different order. Until the end user saves the data, the temporary table is not touched. The end-user can “restart” the process by reloading the temporary table into the INDD table; thus, preserving the original data. If the user is satisfied with the balance of orders going to particular production orders, they can save the data to the temporary file.
At this point, the original data has not been touched; so, the process could be “restarted” using the original data at any time. When the end-user is completely satisfied with the scheduling, they can push a “Post” process, which commits the scheduling to the Oracle tables. We have never encountered any issues with the IMDD driver and the learning curve is not step.
Currently, we are in the process of converting several global queues to IMDD to improve performance of accessing reference data. I would highly recommend the use of the driver. One caveat is scope. You need to instantiate them on the thread where they will be used if you aren’t making them global…
queues are fast it depends on how you structure them and how you access them.
that is they are fast once you have the data IN MEMORY.
clarion uses the same record group internal structure for both queues and files and groups.
all data in the groups is access by the same generate code.