Strategic question: updating (replacing) a complete table at runtime

[Wolfgang Orth]

Hello Bruce and all,

this is a strategic matter I am chewing on.

At startup the webserver reads a Product.TPS into a MEMORY-table.
When the Webclients (Clarion/NT-programs) start, they download this
entire table for the use during its work. This table is completely used
for read-only on the client-side.

Now someone on the server-side will have a program
(likely Clarion/NT-made web-client also) to modify this table.
Think if a complete replacement of table.
(Skipable details: The .TPS is a list of drugs.
The pharmacist can flag products, which are in stock.
Nurses may toggle between ALL drugs / Recently available drugs.
No product is purged, they are just flagged differently.
However, the pharmacy may produce their own nutrition solutions etc.
Those homebrew products are planned to be added to
our MEMORY-table of the drugs.
And those homebrew products can be replaced / removed.
Not on a daily base, but this homebrew-fraction of the table is volatile. /skip)

From this moment on, the data on the client-side are different from those on the server-side.

How do I update this MEMORY-table on the client-side?
The client-user may have one or two procedure open,
where this MEMORY-table is in use. I would not want to
drag away the chair they are sitting on.

One idea I had was to signal on the client-side with a
floating WinEvent-message bottom right-hand corner, saying
"Please close this MDI-Child, a new drug list is lingering for an update".
There is a  good chance that this message is ignored or misunderstood.

A focus-grabbing MESSAGE() is no option. (How about CS Messagebox()?)

Alternatively I could wait for the MDI-child to be closed, then quickly
request and download that modified list. But my program has two
different procedures, both using this same MEMORY-table.
So closing one would not help much, if the second remains open.

One other idea I have to keep the homebrew products separated from
the general druglist. This would be a tiny list, which could easily be sent
each time a procedure opens. But whatever I do, it seems to be the
same problems as with disconnected apps.

How is this solved with "Disconnected Apps"?

Actually I see two questions:
How to solve this technically and how to treat the user?

Thanks you very much for your patience to read all this lament.
Wolfgang

[rjolda]

Hi Wolfgang,
It seems like you have 2 different information sources -
1. Drugs
2. Homebrew drugs

We use NDC codes to identify each drug - this is often a good starting point to identify drugs.
Homebrew drugs do not have an NDC code.

Since Homebrew Drugs is volatile - I would suggest that it should be in a separate table and as you noted, it could be downloaded with each client connection.  You could also consider a timer and change log on server that the clients could query and download changes - e.g. any changes to the Drugs in the last 10 minutes? If yes, then the client can use a change log to make individual changes to the memory table in their client.  If yes to the Homebrew drugs, then download the updated Homebrew drug table and replace in client memory.
It depends on how critical the changes are as to how often you want to query the server.

Rather than do an update on a timer ( or maybe with the update) let the user do a query against the server for a particular drug from table 1.  E.G. I want to see if Drug xyz is still available right now - my client says it is - so lets check inventory and set some aside for my use.

As far as multiple procedures - using the same memory table - depends on whether they are running in a browser  (web client) or windows thin client. 
If windows thin client, then you can make the two procedures that look at the memory table modal and aware to the EXE - then you could have the EXE close these and update the memory tables and offer to re-enstate one or the other.

Web client may be easier?? Maybe store a global server queue value and force update of browse or push something to open clients to tell them that the data has changed on the server and the memory table will be updated.

I have not played with disconnected apps but it seems that the checking timestamps of change logs on disconnected client and server could force background memory table updates. 

Maybe timeout on windows that use the memory tables - close them - e.g. after they are open for 30 seconds - now the data could be too old so window will close.

Seems like the old banking paradigm.  If a user has $100.00 in their account at the start of the day, how many $10.00 withdrawls could they do in 24 hours if the data is not real time???

Just some thoughts that might help you begin sorting your problem.
FWIW,
Ron Jolda

[Wolfgang Orth]

Hi Wolfgang,
It seems like you have 2 different information sources -
1. Drugs
2. Homebrew drugs

We use NDC codes to identify each drug - this is often a good starting point to identify drugs.
Homebrew drugs do not have an NDC code.

Hello Ron,

thank you a lot for your input, it was very valuable!

At first I was intrigued to reply to every single line you wrote, but then I thought, that this might become a very boring thing for all.

Just two things:

Yes, we have an equivalent to NCD, its Pharmazentralnummer PZN. And a second yes, that those homebrew product will likely have no NCD / PZN. However, we need one. So we demand one. If none available, I will simple put an 8-char GUID into the appropriate field during import as a bogus NCD / PZN. This will not hurt, because it it used nowhere else but in this prograam.

The second thing: Timestamp! Yessss!

I will simply store the timestamp from that very moment of a modification by the pharmacy. So the only data I have to request then is this single value, not the entire table. My Client.exe (no browser-based app here [yet]) communicates permanetly with the server on the AppFrame-thread. So once my client learns, that there is a modfied timestamp, it will then display a ?STRING or ?PROMPT on the TOOLBAR, saying that there is "a new drug-list available - after a re-start of this EXE" or some similar wording.

This will be flexible enough! Because this modification is not really time-critical.

Your reply has helped me a lot to sort out my thoughts. Very appreciated!

Thanks again
Wolfgang

[Jane]

Wolfgang,

That can work well.
I also have some apps that just check a server for a "master timestamp" to determine whether any updates are available.

This can be done by polling or have the timestamp pushed by web socket.

Jane

[Bruce]

Hi Wolfgang,

Your situation sounds like a combination of NetRefresh (to refresh open windows) and WebSockets (to "watch" the server for file changes).

Cheers
Bruce

[Wolfgang Orth]

Wolfgang,

That can work well.
I also have some apps that just check a server for a "master timestamp" to determine whether any updates are available.

This can be done by polling or have the timestamp pushed by web socket.

Jane

Hello Jane,

unfortunately I am still with Nettalk 9, eagerly waiting to upgrade. So, Websockets are no option right now, but I have a kind of permanent communication between, so I can get that information to all clients in a timely manner. Its not up to the second, but its not really time-critical.

My real problem is, that I will have that to be replaced table opened by two procedures on the client-side. The App-Frame now will know about an updated MEMORY-table, but (from my understanding) it needs an OPEN(table, ReadWrite + DenyAll) for replacement.

So, this is my plan (for now): Once the App-Frame has learned from differening timestamps, that a new table is loaded on the server-side, I will display in some friendly bold green letters, that the user is invited to restart the client-program, to obtain the latest and most recent product list. This will be a save and convenient way to get this update done.

Lets see, what Bruce will tell me about NetRefresh during the next webinar.

Enjoy the Easterbunny! :-)

bye
Wolfgang

[Bruce]

NetRefresh, in this context, would require NetTalk 11.

cheers
Bruce