Refresh dataset on another window

Ignition
,
1

From a popup I would like to refresh the main windows dataset. Updating a table is easy with:

win2 = system.gui.getWindow(“excel/experience”)
system.db.refresh(win2.getRootContainer().getComponent(‘tableExperience’),“data”)

but I have a custom dataset property on the root window in the main window, and I am having trouble finding out the syntax:

win = system.gui.getWindow(“excel/negate”)
system.db.refresh(win.getRootContainer()," data")

any suggestions of the proper syntax? I’ve tried a few different variants all of which don’t refresh the dataset.

Thanks!

2

Provide the custom property name instead of “data”.

1 Like
3

The custom property name is Data, should the command work?

4

Case sensitive.

5

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.

6

Blegh! Really?

7

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

8

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.

1 Like
9

Fair point about the default string conversion, and that my gui refreshing is now deeply tied to the query itself.

I’m also not a fan of query conditions that factor out to no-ops in the DB .

Can you explain what you mean here though? I never heard the term no-ops nor do I know how it applies here.

10

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.

Think:

SELECT * FROM YourTable WHERE 1=1
1 Like