I suggest that you track the sending of the emails. Right after your Send Mail step, insert an error capture. Something like the following in psuedo code:
Set Variable $lastError to Get( LastError )
Set Field emailStatus to $lastError
If $lastError ≠ 0 //the send email generated an error
do some appropriate action...
Goto layout Response
In the script steps above, I am assuming you have a field (I called it emailStatus) in your table for storing the status code of the send email operation. The other thing you should have in your table, are a couple of standard "auditing" type fields that capture the record creation timestamp and the record modification timestamp. I would also recommend capturing the account name of the record creator and record modifier.
This will allow you to see what is going on so you can present some facts/statistics to the IT department if needed.
In the FM Help for error codes, the last ones 1501 through 1507, all deal with email. Error code 1506 is the most generic one and the one most likely to happen. This tells you that FM attempted to pass the email to the server, but the server rejected it.
You can then go to your IT and show them the exact date and time when emails are getting rejected. They should be able to look in their email server log files and see that the server received a request and so forth.
One other thing to verify is the information you are submitting to the SMTP server. Is the information consistent? By that I mean that for each record submitted, you have valid values in the TO field and other fields. If you are exposing some other fields such as the From, Reply To, etc., then this has to be checked. Some mail servers are quite picky about values in these other fields or even having a value at all.
I had a very similar issue a while ago with e-mails sometimes working and sometimes not.
The errors that FileMaker were returning weren't particularly useful so I decided to remove FileMaker from the equation and I used telnet (I think) to connect to the SMTP server directly and issue commands.
I was able to see from that testing that the connection to the SMTP server was very unstable, often the commands I would issue via telnet would time out which was proof enough to me that there was no issue with FileMaker and it was in fact the SMTP server and/or the network that were the problem!
In the first instance I would work with your IT department to confirm the quality of the connection to the SMTP server from your FileMaker server.
I did as you suggested, and added the script steps you outlined. Now I can gather data. I didn't know how to do this, and feel like at least now I might have a clue what to look for. The best part of this, is that my IWP users will now be notified that their information has not been sent. If $lastError ≠0, I send them to another layout that gives them the option of going back, checking to make sure that say, the email address they entered was formatted correctly, and then try again.
I'm going to try to get a group of teachers to "test" it for a few days, then I'll report back.
Thanks for your response. I am afraid my level of expertise would not include doing what you did, and I don't think my IT department would grant me that level of access, but I am curious. When you determined that the issue was the instability of the connection, were you able to get it resolved?
Sometimes talking with my IT guys just leaves me more confused than I was before!
As it turns out by the time I had discovered where the problem was we were just about to move to a new network infrastructure that included a different SMTP server that didn't have the same problems.
So no sorry I didn't get it resolved, we were fortunate enough to side-step the problem!
However the fact that the new SMTP server was stable just confirms that it was the old SMTP server/network infrastructure that was the problem!
I would be pushing back onto your IT department for some extra support and help troubleshooting the issue!
I hope you have better luck getting your issue solved!
Update: this is working beautifully! I changed a few things. I added a new table for errors, and told the script to create a new record everytime an error is generated. this gives me a nice layout with the timestamp, record ID and the error code in a list view. Very helpful to me and to the tech guys. I have found several errors that I assumed were erver errors, and in fact were due to other things within my control. Having very specific data seems to get their attention to the issue, and I think we are well on the way to getting some answers.
Thank you for helping me to look at this in a different way.
I believe that the suggestions you got where both usefull and did set you on in a good direction.
Let me suggest that you also do this to give better overview and debugging:
- Create an extra email address/mailbox for your domain.
- Send all mails bcc to this adress.
- Create a log entry in the database (as you are doing now, if I understand the comments correct) for each mail that should have been sent.
Now compare your bcc email box with your log. They should matc each other.
... I am of course assuming that you are testing that the person entering data can not submit without entering his/her email address?
Yes, I have been doing both of those things. I hope to stop copying myself at some point when I get some consistency.
Thanks for your suggestions.
Update: I wish I could tell you what the IT guys did, but emailing seems to be quite consistent now. One very important thing that I learned is that in my case, very few emails go through when I am accessing the database remotely, but they are now consistently being sent throught IWP. I am not sure why this would be but since my users will all be on IWP, I can live with it, and I need to move on.
Thanks to all who offered help and suggestions!