One trick I use to refresh data for a client (or globally) is to use a tag. Then you need to increment the tag to trigger a refresh. For a client tag and global tag it’s the same technique, you want to include it in your where clause (I always put it in the front so I know its not hidden)
WHERE {[client]refreshData} = {[client]refreshData} AND {[default]refreshDataGlobal} = {[default]refreshDataGlobal}.
Then changing the client tag from 0 to 1 (or vice versa) will trigger a refresh for your client, or doing the same for your global tag will refresh the data for all clients.
Well I found it in the existing code base and I didn’t think it was bad, easier than trying/excepting to grab a window then a component to refresh. I think its only valid with the Legacy DB Access (maybe?) but that is the how the project I mostly work on is set up anyways and has all the SQL queries hardcoded into component bindings. I know its ugly but compared to the rest of the spaghetti code I have to work with its elegant by comparison lol. Besides being ugly but any other problems with it?
If I had the time to refactor I would be making named queries with long caching period and manually refresh when a new record is added/updated/deleted. Alas, I would need a lot of time to refactor. Gets more complicated when I have user (not role) specific where clauses/group by clauses for data showing on the same component blegh
You ever just want to tear down a project and start it all over? lol
Ha! Too many times to count. One must be careful to constrain the Not-Invented-Here syndrome, though.
More seriously, anytime I see curly braces in a query, I cringe. One is at the mercy of default string conversion of whatever object is in the braces. I'm also not a fan of query conditions that factor out to no-ops in the DB. Not only a big boundary violation between data model and presentation, it is easy to screw up the logic when other conditions are present. Maintenance nightmares.
Now, using a tag as a notification method is efficient. But I would implement it as a binding on a custom property, with a change script issuing the appropriate system.db.refresh calls. Probably just one binding on the root container if there are multiple consumers in one window.
I have always heard this used in reference to a statement which requires some amount of processing but could be omitted from the statement without altering the results.
no-ops is short for no operation, and essentially is a do nothing clause.