Thank you for your post.
I can't determine why it worked previously but not now.
The best test is to pull down the File menu and select Send Mail. Set it to SMTP server, and specify the SMTP server. Is authentication required? If so, this could create a slight bottleneck depending on what was changed on the server. Assuming there is no authentication, send an email to yourself through the SMTP server and check to make sure you receive it. This is the simplest test.
Any additional information you can provide about how you send information to your SMTP server may be helpful in determining possible causes.
We don't use authentication to send mail from the SMTP server, so that isn't an issue. If we send mail from FM client, it gives us a #1506 error the first few times we try then finally it will send successfully.
When we send mail via telnet to the mail server, it works fine.
Using the packet sniffer Wireshark, we were able to determine thatthe server is sending the correct messages to FM, but FM client immediately sends a "QUIT" packet to the server on those first erroneous attempts. Then on the successful attempt, for no apparent reason, FM client decides to "play nice" and sends the appropriate "HELO" message to the server.
Hope that info helps to clear things up a bit!
Thanks for the additional information.
I'm still not sure what changes were made on the server, but for now, let's assume either FileMaker Pro became corrupt or the database file. Therefore, create a new database file, pull down the File menu and select "Send Mail...". Try sending to the SMTP server again. Does this work? If so, then your original database file may be damaged. With the original database file closed, pull down the File menu and select "Recover". Select the file, let it default to Recovered file name, and save. FileMaker Pro will do its best to clean up the file. It is not a cure-all solution, but when finished, open the recovered file and try again.
Do you have a backup from previous to when this problem started? If so, try it from the backup file.
If none of these options work, then uninstall and reinstall FileMaker Pro. After reinstallation, launch FileMaker Pro, open your file and try again.
If this still doesn't work, then you will need to find out what exactly was changed on the server.
Just curious, what exactly is Recover doing?
Well in FM10 recovery has been changed to have more personalized options to where you can pick and choose what recovery functions should be used.
However, traditionally Recover scanned the blocks in the system and if there were an invalid blocks dropped them.
That is why it is recommended that a recovered file not be used going forward but rather the data exported and imported back into a clean clone BACKUP from before the corruption setting in. The file may look like it is working properly and many are tempted to use it again. However, it usually comes back sometime later and bites you.
General rule of thumb is that recover is a last tool to try and grab your data if you are having issues with your file since data is the most important thing.
Picture a wrecked car as your database and the passengers trapped inside are your data.
The recover process is then the "jaws of life" being used to destroy the car in order to rescue the passengers by changing your damaged database into something from which you can import the data into the clean clone that Mr. Vodka is recommending.
Unlike real "Jaws of life", those changes may fully repair your file, but there is no way to tell for sure, hence reverting to a back up is best practice.
Hmm... We've had the same issue on numerous client machines, so the FM pro client being corrupted client is very unlikely.
However, we made a copy of the database and tried doing the recovery. The email worked right after that; however, it works now even on our original database (the unrecovered one). So it's not really a scientific test... :-( The recovery "rebuilt" a number of things, including schema, relationships and a number of records.
So if we stick with the recovered file, is that really going to be problematic in the future? The only reason I ask is because our database is ~2.0GB and rebuilding the database structure and reimporting the records will be a HUGE undertaking. Or is there a simpler way to do it?
The file may look like it is working properly and many are tempted to use it again. However, it usually comes back sometime later and bites you.
Learn from our previous mistakes...
LOL thanks Mr. Vodka, I'll take that to heart and assume that it's worth the effort to create a new database and copy the records over.
Is there a "best" way to do this? Do we actually have to manually recreate all tables and fields and relationships before importing the old data? Or is there an automated way to do this?
I've even had a recovered file behave differently after the recover reported "no problems found".
( One obvious explanation is that the index rebuild straightened out a scrambled index, but in this particular case, a script that used Print to print without showing a dialog behaved differently after the recover. )
You dont have clean backups? You should always make it as part of your business to have regular backups. Each time a new version is created by adding new functionality, etc then you should save a copy of it as a clone and store it. This way if you ever encounter corruption, you can just export the data and import it into a copy of your clone.
Exporting the data as XML and then importing them is the safest way. Merge files ( .mer ) are pretty safe too, but there has been debate about whether or not it can strip some unwanted characters out properly.
We do have numerous backups... however, we don't know how far back the corruption goes. We started having these issues 4 weeks ago and we've done so much work to the database (in terms of schema, layouts, etc) it would be a huge loss to just dump all of that for a "clean" version of the database structure from four weeks ago that we assume is uncorrupted. We're just trying to find a happy medium :-/
One option to save rebuilding a table one field at a time:
Use import records and specify a new table. It'll pull in your data and the field defs as well. You will need to use care with relationships and additional table occurrence references in your new file. These have to be created by hand. If your calculation refers to something that doesn't exist in the new file, it will be enlosed in /* comment */ brackets to avoid error conditions. You'll want to check for these after import and edit them to fix the error and delete the brackets. You can also copy and paste layout objects, import scripts etc.
Hmm... Alright... it looks like this is going to be rough lol. We've got 150 tables and each table has numerous fields with calculations, etc... so this is going to be a project lol. :-P
Thanks for all of your help... I'm hoping the recovery is really what fixed the email problem. If I find any more clues, I'll post back again. Thanks for your time, everyone! :)