Will Loving

Everything was correct except the enclosing folder which was Desktop and did not have permissions (it was a test...I would not normally do backups to the desktop). When I moved the folder to the root level of the HD, it worked. filemac:/Macintosh HD/Backups/

I'm running FMS 19.2.1 on Mojave 10.14.6 (and yes FMS 19 is qualified on Mojave), have enabled Full Disk Access for fmserver_helperd and continue to get "The path is not valid" error when setting a Backups folder. The "Backups" folder has Permissions for fmserver and admin set to full Read & Write.

bsin's calculation actually works well except that with the images I'm using the number need to be slightly higher than 100. Using a "not found" image called "9.jpg" (five characters long) the character count for Base64Encode was 106; for image 10.jpg (6 characters long) it was 110. Longer image files names would likely be higher but not by much. Since the character length almost any image is going to be, depending on the image size, hundreds to hundreds of thousands of encoded characters, a slightly higher number - I'm using 200 - seems to work fine.

I'm setting up a scripted Quickfind for a project and in the course of testing it find that it is returning case-sensitive results, so for example if I enter "human" in the QF field, it is only returning results that match "human", ignoring "Human". I've used QuickFind before and have never seen this behavior. I know how to create a workaround for it: creating a calc field for fields I'm performing the Find on with the Lower( ) function and doing the same using Lower( Get(QuickFindText) ) for the script step, but I can't figure out why it's only doing case sensitive Quick Finds in the first pl

Agnes, can you post a demo file for the timer in your screen shot?

All, see this post: http://fmforums.com/forum/topic/92466-webdirect-prevent-enterreturn-in-data-entry-field/?hl=exit+field Also, in one case I was able to use a Popover window with the Search field in it and hitting return worked to close it.

I am aware of the Security feature added in FM 11 to restrict external File Access in the security settings, but I was recently stunned to discover if this feature is not set, a user can create a new blank database file, and then reference a password and privilege set protected file file without ever having to enter a username/password for that file. I always assumed that in such a circumstance a user would be denied access unless they entered a valid user account for the file that they were attempting to access. On the contrary, I was able to import tables, scripts and data into my blank

One additional error that you might encounter in moving a PHP Site Assistant generated site to a remote server is that you get an error that looks like the following: Warning: session_start() [function.session-start] Cannot send session cookie - headers already sent by (output started at D:inetpubvhostsmydomain.commygeneratedsitehome.php:2) in D:inetpubvhostsmydomain.commygeneratedsitehome.php on line 10 To solve this you need to remove the following text from all pages, starting with the home.php page. You can use Dreamweaver to do a "Replace All" searching on Source Code

How to move a PHP Site Assistant generated site from a localhost to a remote server The above questions took me a number of hours to solve and since it's seems that I'm not the only person who has had this difficult, I thought I would post the solution that worked for me. Problem You have setup FM Server on your development machine and used it to host your FileMaker file(s). Using the PHP Site Assistant, you connect to a FileMaker database and generate a site that is also hosted locally by Apache or IIS. Everything works great so you move the site and databases to remote servers.

Internally, I believe FM uses ASCII 11 as a CR rather than the standard ASCII 13

JavaCompanion seems to be a way to use Java programming within a plugin rather than what I might be looking for which is a way for a Java app, while talking to FileMaker via JDBC, to trigger a script.

Someone just pointed me to 360works free ScriptMaster plugin which can apparently trigger a script on a field value change. It seems to indicate that it can do this on FM Server as well, so I'm looking into what's possible. Seems like a great plugin. http://www.360works.com/scriptmaster/

Hi Lee, Thanks for taking a look at this. For background: We have a Java based application that manages auctions, passing data between FileMaker and MySQL servers and back with the Java app being primary control interface. We use a the FileMaker interface when doing non-web auctions. I only do the FM part and provide what is needed by the Java/SQL programmer. In the past, in the FM6 iteration of this system, the Java app used ODBC to save all completed auction records to a buffer file. We then periodically imported those records into a 'sold lots' file, performing a number of st

I'm creating records in FileMaker via JDBC using a Java Applet . After the record is created and populated - which works just fine - I need to trigger a script to do other processing of the record. JDBC and the SQL query language does not appear to offer any way to do this. FM10's Script Triggers are object specific so that appears to rule them out. I can think of work-arounds like using a timed script, but I want the post processing to happen immediately before a user get ahold of the record. We're using both FM9 and FM10 with various clients who have this solution so ideally the answer

I have an FM9 scripted import that imports - FM to FM - each of the tables in a previous version of the solution. Each table import is handled by a sub-script of main Import script. Everything works fine except that for each import I am prompted to enter a Username and Password for the Source file. Both Source and Target files are identical and have the same Accounts and Passwords. I can get around this by asking the user to open the source file first, but I'd rather be able to script the opening entirely and have the pw dialog only appear once or not at all. In order to determine the loc