Lem Alpha

Do you have access to an older version of filemaker pro ? If you have access to a v13, you can access "manage security" without the first dialog.

For the moment, your [fullaccess] account has no password, so you may access security by just entering your account name and leaving the password blank. Then you'll set a password, and when you validate the settings, it will prompt you with the same dialog again, which you will then fill with your brand new password.

Maybe the "Require Password-Protected Databases" setting was not enabled before ? Anyway... You can "Download Database" from the same menu (in your first screenshot), then delete the db from server (trash icon on the top-right) Open the file locally with Filemaker Pro, set a password, then upload it again to FMS using "Share / Upload to server" in filemaker pro.

It is the file we are talking about.

That's the problem : your filemaker server is set to only open files where [fullaccess] accounts are password protected , but from what you say, none of the accounts has a password, so obviously the [fullaccess] doesn't have one. In order for your file to open, you'll have to set a password for [fullaccess] accounts. Which is more than highly recommended anyway. Other obvious security flaws that prevent a file to be opened : "auto log in with account :" set with a [fullaccess] account, or a Guest account with [fullaccess] privilege.

"Open" is what you're looking for, which for some reason doesn't work for you, obviously. What does the log say ? ("Log Viewer" in the left pane)

Yes, as our German friend's doppelganger just said : go have a look ! Even if it's only through the eyes of a kid at a magician's show ! It's worth it.

This is also a good remark. In my case of making it easier for users to search for emails, it was never an issue because when someone puts in the @ it means they put in a complete address, so there shouldn't be any parasitic results. But of course, for such a scripted search, it would not be bulletproof then. Thanks for pointing out these caveats, both of you.

True. But I have seldom seen emails encoded with upper case, so I think the benefits of users being able to search for emails using @ are greater. And just making this field an auto-entered calc Lower ( Self ) would prevent indexing upper case chars. I was specifically speaking of users manually searching for emails, of course.

Really long shot here, but would you consider having an emoji instead of a "real" image ? You could then have a calculation field (= empty or emoji according to your condition) an append it to your merged text ?

Or you could set indexing to "unicode" in the field definition (thanks to JFS for the reminder...) This is especially helpful when such an email field is accessible in search mode for users...

All right, I didn't get this, and it did seem strange to me that such an experienced member would have that kind of questions... I think I did switch parameters a couple of times, and rewrote the calcs, but I've no memory of such problems. I definitely will try to reproduce this one of these days (unless you do come up with a demo in the meanwhile) So, again sorry for the useless answer.

Hi there, I'm not really sure I understand what bothers you about this, so excuse me if I'm completely missing the spot : the order of parametes matters because it's the only way for the custom function to know which string is what. There is no such thing as "parameter name" when you call that function, as there can be f.i. in an URL e.g. google.com/#q=sometext&hl=fr imagine that the server didn't need parameter identification, and that URL was written that way : google.com/#sometext&fr if you switch the input parameters like this, google.com/#fr&sometext the server would try to search for the text "fr" and try to show only pages in "sometext" language... Because it's the order of the parameters that tells him that "fr" is the text to look for, and "sometext" the selected language of the results. And if you switch the expected parameters order on the server, so that the first string he sees will tell him the language and the second the search request, you would of course have to write any URL in that particular order. Same thing for FM custom functions (and internal I guess, though you can not alter these) : in the definition of your CF, let's say BinomDist, you tell FMP that the first string encountered is "successes", the second "trials", etc. If you switch them in the definition, but leave all the written calculations unchanged, FMP will understand that the first value you entered (and meant to be "successes" when you originally wrote it) is now the value you want for "trials", and so on. So you would obviously have to rewrite the calcs with the "trials" value first, ... Hope it helps.

Just a little follow-up, for those interested : still the same problem in 12v3 and native ExecuteSQL. Updated issue report can be found here : http://forums.filemaker.com/posts/4d4bb0da3e

Yup, but my problem was to launch a script by calculated name... (sorry if this wasn't clear) So I'll try some other way, thanks for your answer. ;)