× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



But, I think everyone is missing the point... or the "big picture" here...

A true "cache" should be 100% totally transparent to the user, other than improving the speed of processing.

IMHO, it should NEVER be necessary for an end-user (or developer) to tell the tool to "refresh" anything that is "cached" ... the tool should easily be able to verify, in the background, and silently refresh and keep the cache "up to date" automatically, e.g. whenever you are connected to the host(s), by checking each file 's last changed date on the host and comparing it to the date the file was downloaded into the local cache.

[I will admit that there might be some circumstances where you might want to be able to temporarily turn off this behavior, but for the most part, I think the default behavior should be to automatically keep the "cache" up-to-date.]

Apparently, ever since the invention of the web browser in the mid-1990s, we all became conditioned to the idea of a local cache of files, and having to tell the browser when to "refresh" or "clear" the local cache. But, that does not make it the "right" design decision. Although, I understand the rationale for that decision at that time -- we mostly had much slower dial-up connections to the internet back in those days. But nowadays, most people have some kind of high-speed internet access. So, I think it is high time to change the concept of a "local cache" back to what it is supposed to be, a transparent way for the local client-side software to be able to do some things faster than would otherwise be possible without a cache. This should be invisible to the end user (or developer) using the tools -- other than the fact that they might notice that some things run faster (once those files have been "cached".)

Sincerely,

Mark S. Waterbury

> Joe Pluta wrote:
DeLong, Eric wrote:
I have seen this as well. If I'm remembering this right, this usually happens when the field(s) is output only. It seems the outline view is populated from input record formats.
This I haven't run into. I'll have to look into it when I get a chance.

In other cases, it seems that a cached file description in WDSC is not getting refreshed. This occurs when adding fields to a file, and trying to make those new fields visible to outline. I usually end up clearing the two cache features, end and restart WDSCi.
This is easy to fix... right-click on the file in RSE and select "Refresh Cached Definitions".

Thanks, IBM!

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.