Are actual attachments themselves imported into the database

[Automated Workflows, LLC]

The solution doesn't import attachments into the database. Rather, it may be configured to save attachments into a specified folder, and then import the paths to those attachments into the database. Attachment handling may be enabled via the database configuration window (click "Configure" in the main interface window). There are also some preferences for how attachments are handled in the preferences window of the solution.

[teka]

Can you actually automate the importing of attachments into container fields?

[Automated Workflows, LLC]

No, M2FMI can't presently import attachments into container fields. There are several reasons for this, including...

1) Doing so would greatly reduce the size of the database

2) Handling multiple attachments would be cumbersome

3) M2FMI is written in AppleScript, and there's presently no way to import actual attachment files into container fields via AppleScript. It's only possible to import references to files.

We'll keep this on our list, thought, and will consider implementing it in the future, if we are reasonably able to do so.

Thanks for your feedback.

-Ben

[teka]

You mean increase the size of the database...

You can make a one to many relationship to an attachments table via the primary key of the message...

The real problem is not being able to import the actual attachment data into the container field...that's a show stopper...

You must have a routine that you wrote or use to bring the attachments into the destination directory, un-encode them (binhex or mime) and check/modify filename collisions... It would be much simpler with no checking required to simply import the data for each attachment into container fields.

[Automated Workflows, LLC]

1. Yes, INCREASE. Sorry, that's what I meant.

2. Yes, this could be done. I could certainly do it in my sample FileMaker database, which is provided with M2FMI. This would add a bit more to the configuration requirements, however. In addition, it would add complexity for people that want to use their own database, especially those who aren't FMP experts.

3. Again, importing attachment data into the container field is a limitation of FileMaker's AppleScript support (I haven't checked FMP 10 yet), and not of M2FMI itself. To do it, I'd need to come up with a fairly involved workaround, which would include saving the attachments somewhere, renaming them, triggering a FileMaker script to perform the import, and then cleaning up once the import is complete. Not the most elegant solution.

In any case, again, attachment importing is on my list, and I will try to provide support for this in the future. In the meantime, if you're interested in discussing the possibility of hiring us to develop a custom solution for you, please feel free to submit a consultation request via our website at http://www.automatedworkflows.com/contact/requestconsult.html.

Thanks again for your feedback.

-Ben

[teka]

I'm really not interested in paying for a custom solution that will fork the present code and require me to continue to pay to maintain it. I'm merely trying to suggest solutions and enhancements that many would want in the standard version. There are other solutions available to import mail.

[Automated Workflows, LLC]

Okay, thanks for the suggestion. I will consider it for a future release.

-Ben