Has anyone else experienced this? I enter a uselsx statement into an agent, successfully instantiate and use members of classes from that lsx, and then at some point the uselsx statement disappears from the code module. At that point the code will compile just fine without choking on all the dims, sets, and member references to the now-unknown classes spread throughout the script (and this is a single-initialize-procedure-only agent with no script library usage and no calls to other agents), but upon executing on the server via a back-end trigger (post-delivery), an “Unknown LotusScript error” exception is logged. The error handling routine referenced by my On Error statement is never invoked.
You have two separate issues. The disappearing Uselsx is your real issue. The ability to compile once it is loaded and later getting the Unknown LotusScript error is just an artifact.
I have written zillions (give or take a few) agents and scripts using Uselsx without ever having it disappear. Granted, my agents and scripts tend to be short, but I have never seen this. Does it only happen in 6.5.4 (I have never used that version for development)? Is there anything you can think of that is different about these scripts? Do they come close to the 64KB limit, even if that limit is theoretically no longer there?
I don’t have a version other than 6.5.4 handy here at the office; but I think one of my machines at home may be 6.5.1. The problem, of course, is that I haven’t determined how reproducible the vanishing is, so I’ll be testing an intermittent issue. Yum.
As far as script length, no, the agent in question is only 260 lines long including comments.
All the code does is make one odbc connection, read from a few tables via that connection, lookup into the NAB, add records to two back end tables via the odbc connection, and compose and send a message using rich text classes. It’s a post-delivery triggered agent, and it also writes to each inbound doc that triggers it. That’s pretty much it.
As I said above, I haven’t been able to determine either the trigger or degree of reproducibility of this behavior. The best guess I have is that it might be happening some of the times that I switch the trigger between post-delivery and manual for testing purposes.
Yeah, I didn’t think that this would be something that could really be debugged in this forum; I was hoping that this was known behavior that someone else could verify. Since I figured out the cause of my execution errors, I’m good – I just had this derned curiosity, ya know?
Just a thought. Could it be that the actual LSX is on your local PC but not on the server ? So when the agent runs on the server it can’t find the LSX ?