Will Loving

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 place. The specific variables are that: 1) I'm using FMPA 15 ; 2) It's a simply scripted QF, nothing out of the ordinary; 3) The fields being searched are all Indexed text fields; 4) the fields ARE locating in a separate file. In checking around I did find that QuickFinds using External SQL data sources ARE case sensitive by default, but that doesn't address the issue where the records are in another local file but it's all FileMaker...

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 file, as well as directly manipulate data in the accessed file, without any apparent restriction. I still have a number of clients that are using a mix of FM 10 and 11 and so cannot use the FM 11 and up File Access restriction at this time. Are there ways to block this kind of external file access in FM 10?

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 and replacing with nothing to remove this "header" so that each page begins with the "<?php" tag

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. And, the home page comes up, but other than that, nothings works. Solution: The reason nothing works is because the site is looking for the database on "localhost" and it's no longer there. Why? When the PHP Site Assistant generates the site it neglects to include the FileMaker.php file and the FileMaker directory. To locate these files, go to your FileMaker Server directory -> Web Publishing -> FM_API_for_PHP_Standalone.zip Unzip the archive and place the FileMaker.php and FileMaker directory at the root level of your generated site. To set the location of the database server, go to FileMaker/conf/filemaker-api.php and open in a text editor or website management program like Dreamweaver. Change line 29 to include the IP address or domain of your FileMaker Server: This is the default configuration which you should edit for your server: $__FM_CONFIG['hostspec'] = 'http://127.0.0.1'; when you are done it might look something like this with a domain: $__FM_CONFIG['hostspec'] = 'my.domain.com'; or like this with and IP address. $__FM_CONFIG['hostspec'] = 'xxx.xxx.xxx.xxx'; The "http://" is apparently superfluous but you can specify the port if needed by including a colon adn the port number, e.g. 'my.domain.com:80' Save the filemaker-api.php file and upload both the FileMaker.php and FileMaker directory to the root level of your PHP Site Assistant generated site. The site should now properly access the database server at the address you specified.

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 steps including updating linked inventory records. We are now working in FM10 and seeing if we can simply add the newly sold records directly to the 'sold lots' table. The issue is that we still need to perform the post processing steps of updating the linked Inventory records, calculating commissions, etc. And, that processing needs to happen immediately before someone using FileMaker tries to access the record. So, I need a way to trigger a script after the record is created via JDBC. If we were using PHP, we could easily do this, but we're not. And I'm pretty sure that if we were using JDBC to FileMaker Pro (as opposed to FMS), we could trigger the script using a plugin like ZippScript or DoScript, which are triggered via the auto-enter by calculation part of the field definition and don't rely on an object on a layout the way FM10's script triggers do. The problem comes with the fact that in most cases we are not talking to FMP but FMS using JDBC and FMSA. I don't know if FMS/FMSA will use or recognize a plugin like DoScript place in it's Extensions directory. To clarify one other thing, this setup has been in development for a long time. There might be alternate ways of doing things like using PHP but that's not going to happen in the short term. My options as far as I can tell, are: 1. Find a way to trigger a script after the record is created 2. Hide the records from the end user until a script can be run manually or via a Timed script 3. Go back to the way we did things before where we put all records in a 'buffer' table and then wait for the user to click "Process incoming records"

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 would not be 10 dependent, but if there is a way to do it with script triggers we would consider moving them to 10.

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 location of the Source File, which will vary from user to user, I'm using the Troi File plugin's "Select Folder" function, and capturing the path to a variable. In order to launch the Source file, I've tried using the Open File (hidden) script step, but have discovered that FileMaker does not support the use of Variables in File References to FileMaker Pro data sources (as noted in the Help file). I've also tried using the Troi File Launch function, but for some reason nothing happens, even though the result code is "0", which means that the function should have succeeded. I'm sure I'm not the only one to encounter this problem...any solutions? Thanks in advance! Will Loving