jjjjp Posted October 5, 2020 Posted October 5, 2020 I host a database on my university computer to administer a series of group workshops for the undergraduate community in fall and early winter terms. Each morning at 7, FM Server executes a script to send out email reminders to all workshop leaders for their upcoming presentations; provide them with essential information about location; etc. We had a ransomware attack on my College's servers last winter. Fortunately, the attack happened after the workshop schedule was almost completed, but the emails stopped going out successfully after the College recovered from the attack. The error code is 1502: Connection refused by SMTP server. To complicate matters, the IT person at my college was promoted to a another unit, and the acting IT person knows nothing about FileMaker and is part-time only for the moment. When I asked him to look into possible reasons for this error, which never occurred before the ransomware attack, he sent me the log file, which is full of "scripting errors." The implication seems to be that there are a lot of errors that could easily be causing the database not to complete its task properly. I would ideally like to eliminate these errors so that the IT person can clearly see that that's not the problem. (It seems to me that the term "scripting error" creates an unfortunately inaccurate picture to outsiders of what an error in FileMaker means. It suggests a bug.) It also wouldn't hurt for my sake to have a pruned down list. All of the errors on the log seem to be of two types: (1) Perform Finds that find no records; Go to Record/Request/Pages [Last] that don't land on a record because the found set is empty; etc. (2) steps involving opening, closing, and resizing windows. It is easy, I understand, to get rid of errors of type (2). I just need to test whether the application type contains "Server" before executing those window-related steps. But errors of type (1) seem not necessarily to be suppressed on the log even if Error Capture is set to On. Am I right to conclude that turning on Error Capture doesn't always suppress errors on the Server's error log? Or am I doing something wrong in the way I am capturing errors? What I find confusing is that turning on Error Capture does seem to suppress the error for sending the email. Here is the relevant code: Set Error Capture [ On ] Send Mail [ Send via SMTP Server; To: $EmailAddress; BCC: $BCCAddress; Subject: $Subject; Message: $Message; Name: SystemGlobal::SMTPName; Email Address: SystemGlobal::SMTPEmailAddress; Reply-To Address: $ReplyToAddress; SMTP Server: SystemGlobal::SMTPOutgoingServerHost; Port: SystemGlobal::SMTPPortHost; Use TLS; Authentication Type: Plain Password; User Name: SystemGlobal::SMTPUserName; Password: SystemGlobal::SMTPPassword ] Set Variable [ $Error; Value:Get ( LastError ) ] Set Error Capture [ Off ] The reason I know about the error is that my database keeps it's own log of the truly relevant errors. (Also, I am CCed on the emails and can tell they're not coming.) I'm also wondering whether anyone can provide insight into the typical cause of a 1502 for a database hosted on a server. I am currently running the 7:00 am script manually from my home computer—a far from ideal workaround that cannot be sustained into the future. Thanks in advance.
Recommended Posts
This topic is 1578 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now