Subject: RE: Database not refreshing after scheduled agent runs.
“When the agent runs as scheduled, there are no documents in the database - therefore, they are missing from the database.”
OK, so we know, that the agent runs, but it does not create documents. Good. Well, not exactly yet, but we’re getting closer.
“When I run it automatically the documents are created, however I have to hit F9 to refresh the view for them to display.”
These calls
Call idView.Refresh
Call workspace.ViewRefresh
should be sufficient to refresh the view, if any documents have been imported. You might also check the view’s On Refresh setting on the Options tab.
“I will check with our server admin as to the ODBC datasource being defined on the server, but I’m pretty sure it is since we’ve been running other agents against the server.”
That could be one - rather obvious - reason. Other possibilities: You are retrieving the parameters for the ODBC connection from a configuration document. If the server that holds your warehousctacs.nsf is not the one, on which the agent is scheduled to run, it could be, that they don’t trust each other. If the server on which the agent runs is not included in the list of trusted servers on DDAS2/Notes, you will never get back the required data to connect, even if the data source is there.
Btw., I must admit that I don’t know what the fourths parameter for ConnectTo does. According to Designer help, there are only three parameters).
You should definitely add some error handling to your code. See help for On Error. If you are as lazy as me and still want finest quality error reporting capabilities, check out Julian Robichaux’s ingenious OpenLog application on openntf.org. You will still have to include the basic error capturing yourself.
If your sever runs the remote debugger task, you can even debug the agent while it is running on the server. Ask your server admin, if this is enabled and have a look at the prerequisites in Designer help.
“So, you’re suggesting that I have the agent run on all new or modified documents rather than all documents in the database?”
No, that wont do it. The ODBC data source seems to be the leading system, so there are probably no changes made to the Notes documents. You should just not delete all documents and re-import all records every time the agent runs.
If the records you import have some flag like a distinct version number or a last changed date, store that in your Notes documents and update only, if this has changed since the last agent run. If such a flag is missing from the original data, you can still compute a hash value for all fields in a Notes document (and store it along with the other data). You could then retrieve the fields from your matching record, calculate the same hash value for the combined field values. Only if the hash values don’t match would you update the existing document.
See this article for more details
http://www.thenorth.com/apblog4.nsf/0/5F6A05E49BDB349285256EBC0054545B
(looks like Andrew has some strange JavaScript running at the moment, but don’t let that distract you from the article)
If your Notes database gets replicated, you should preferably not delete and recreate the document even if something has changed, but ideally only update the changed field values. If there are no replicas, this might not be much of an issue.
“Can you take my code and show me how to do this?”
No, I might just be able to help you learning how to fish, but I can’t server a grilled salmon. (http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/f361921c7f4650fd852573990057118f?OpenDocument)
“You can e-mail me directly. I’m a self-taught scripter, so I’m a little slow!!”
No. If I was a freelancer, I would want to charge you for that, of course. Since I am not, I can’t even do that. Even if you would invite me for tea, the spatial distance would probably not allow me to attend.
Feel invited to post whenever there is something more you have to ask, and I or somebody else may even answer, whenever we have the time to.