Wim Decorte

That's right, but operations on the data in a field very often will force casting into underlying field's data type. Which is why it is often important to know the field's data type so that you know what it is supposed to be.

If it is a field: by querying the FileMaker_Fields metatable with executeSql(), or by using the FieldType() design function. If it is a variable: you can't. Much like other environments where you declare a variable 'untyped' by doing something like 'var myVariable', FM works the same. Except that you don't have a TypeOf() equivalent. As a developer you need to know what you put in the variable. When in doubt just use the right GetAs...() function.

That has nothing to do with data types, what that speaks to is that FM is permissive in that it does not prohibit the user from inputting the wrong data type into fields, it leaves it up to developer to put validation rules in place. FM does NOT treat everything as text as you claimed. Even a variable will maintain the correct data type of what you set into it, including container data.

Absolutely, under no circumstances, make a direct path from finder to where FMS stores its containers. Container data is strictly for FMS to manage and no user should be able to have direct non-FM access to the container data files. With that out of the way, I'm a little confused about your current setup. How is the mp3 loaded into the container field from the ftp site? Can you describe the mechanics here? Perhaps show the script that does it?

When you make statements about what is better than an alternative, please qualify the statement. Why is 'choose' better than IF() or CASE() for you? If two or three different approaches produce the same result, how do you select the one you want to use? Performance? What if it doesn't matter and makes the code less readable?

Sometimes; but: 1) it is usually very fragile - any small update to the website can totally break your 'integration' 2) very often it is not allowed

Or go find the system where they get this data from and see if you can integrate directly with the source?

Note that in excel, the picture doesn't belong to the cell, it just 'floats' on top of the worksheet. The only way to get those out is to write code inside excel or that can talk to the excel APIs to try and save the pictures to the hard disk to then insert them into FM.

You'll find SMTP progressively more difficult to make work, especially with the big providers like Gmail and MS 365. See some of the announcements in this blog post: https://www.soliantconsulting.com/blog/microsoft-graph-api-filemaker-one/ Specifically for Gmail, you have to explicitly enable the "less secure applications" in the account, something that will take away soon. (it was supposed to be already taken away for those accounts who had not already enabled this - but Covid has postponed it a bit). Short story: rethink how you send emails.

Use an API and let the user authenticate so that you don't have to store credentials. See https://www.soliantconsulting.com/blog/microsoft-graph-api-filemaker-one/ Or if you are on AWS, let the AWS instance check out credentials from the AWS key store and push into FM so that you don't have to store credentials at all.

No. And since this is an AWS backup and not a regular FMS backup, you don't need to worry about the time it takes vs. a standard FMS backup nor the disk space it consumes. If that is the reason why you don't want a backup every 20 mins.

This was published back in February: https://support.claris.com/s/article/New-Claris-support-policy?language=en_US Both 16 and 17 will be EOL in September 2020.

Not officially, no. And thus not supported. You only have 2-3 months of support left on FMS16 as it stands - if support is important to you then upgrade to FMS18.

You check on their website and/or you ask the website owner.

None. Except that in general terms grabbing assets from a URL like this isn't a good way to integrate. Does the site have an API that will give you the data in a proper form?