Baloo

Caveat: Site Assistant generated pages can quickly become a nightmare once you start modifying them. If you need custom pages you're much better off building them from scratch To answer your question: When php loads the page it will set the key value pairs from the URL to the $_GET associative array /* for http://www.site.com/recordlist.php&name=Fred&job=Boss */ print $_GET['name']; /* prints Fred */ print $_GET['job']; /* prints Boss */

In the off chance you haven't figured this out yet (and for folks searching down the road), you need to set the second parameter of getField to the index of the repeating field. i.e. $record->getField('FieldName', 2); To get the second repeating value from the field

How much data are we talking about? I don't have too much experience with runtime solutions and as such don't have a handle on their limitations, but the first thing that comes to mind is a Open URL script step that passes the data to a custom php script on your server.

One quick caveat about AJAX Most browsers will always go to the cache for GET requests with the same parameters. So if your $queryString will always be the same but you expect different results (i.e. changes to the DB) you should either use POST or append a unique parameter like a time-stamp to the URL.

The PHP API has access to any (and only) field(s) on the layout you hook it to, so my first guess is that the fields in question aren't on the layout.

What you have is not really an error in the classic sense. It's just a "warning", which in PHP parlance basically means I know what to do, but I didn't get what I expected so you might not either. In this case the foreach statement is expecting an array as the first variable and it isn't getting one. My first guess is that the value-list in question doesn't have any values and what ever code set it made it null instead of an empty array. If the value-list does in fact have values you should look at the code that calls getInputChoices() an see where the second passed variable is getting set.

The current API code will run fine on PHP 5.3 The deprecated "errors" are just letting you know it will cause problems in future versions. You can easily turn them off by editing in your php.ini file look for a line with something like error_reporting = E_ALL and replace it with either one of the following // Report simple running errors error_reporting(E_ERROR | E_WARNING | E_PARSE); // Reporting E_NOTICE can be good too (to report uninitialized // variables or catch variable name misspellings ...) error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE); After editing your php.ini file you'll need to restart Apache before the changes take effect. Also as with any application's config file Make a backup copy before you start tinkering around. That way if things don't go as planned you'll be fine. On a production server it's generally a good idea to send the errors to a log a rather than the screen You can also set those values at run time with the error_reporting function

foreach() takes two arguments the first has to be an array the second becomes the placeholder for each value in the array. That error means that the first value supplied to the function is not an array. Without seeing the code its hard to say more

You're bumping up on one of the many reasons I loath the Site Assistant. I've never tried it with the name field but you can hack JavaScript's document.getElementById() function to access an element with an integer by casting it as a string. function getNumericID(){ var intVal = 1; var elem = document.getElementById(intVal + ""); alert("name = " + elem.name + "nid = " + elem.id + "nvalue = " + elem.value); return; }

You've got a couple of problems. First, the FindAllCommand is only for finding all the records for the supplied layout. Second, the setOmit() function is only available for a compound find request which would look like this: $cpdFind = $fm->newCompoundFindCommand($layout); $req = $fm->newFindRequest($layout); $req->addFindCriterion("COUNTRY", "="); $req->setOmit(true); $cpdFind->add(1, $req2); $result = $cpdFind->execute(); however in my testing it seems there's a bug in the API that ignores the setOmit = true value if its the only request in the compound find i.e. the above actually returns all records where COUNTRY == "" but the following works $cpdFind = $fm->newCompoundFindCommand($layout); $req1 = $fm->newFindRequest($layout); $req1->addFindCriterion("PrimaryKey", ">=0"); $req2 = $fm->newFindRequest($layout); $req2->addFindCriterion("COUNTRY", "="); $req2->setOmit(true); $cpdFind->add(1, $req1); $cpdFind->add(2, $req2); $result = $cpdFind->execute(); However since all you want is a list of all records where "COUNTRY" is not empty the following would be the easier route $find = $fm->newFindCommand($layout); $find->addFindCriterion("COUNTRY", "*"); $result = $find->execute();

The WPE and XML feed can't seem to access "external data sources" via fmnet:/ as long as your presentation and data files are on the same server just change the reference in external data sources from fmnet:/server.host/DB.fp7 to file:/DB.fp7 and you should be good to go.

Per the FM Knowledge Base article "Import/Export Script on FileMaker Server 10" Is it just me or that this render the ability run Server Side import/export scripts nearly useless?

OK what that means is that the binary data is getting hosed when it renders on your production containerBridge.php page. Surfing to the long URL for a container bridge should bring up the image in a browser not the binary data. The most likely culprit is an error message getting inserted into the page. Try scanning through the binary data and see if you can spot any discernible text. Also double check your containerData.php file. Even a single white-space character rendered in front of the binary data will mess things up.

I'm assuming by this you mean if the binary data is an image you can print out the image as opposed to the raw binary data. Just in case you've overlooked the obvious does the daemon have read privileges to containerBridge.php? Other thoughts what happens when you do the following: right click on the place holder image select and copy the URL listed for Location (Address (URL) in IE) Paste it into your browser's address bar.

the only thing that comes to mind is an error message or some other text on the production server's "container bridge" file (i.e. the local php file that queries FMP and draws the image) Look at that page in your browser and see what comes up. If there is any text you should see it along with possibly the binary container data. Once you get beyond the WYSIWYG wizards, I know somewhere between diddley and squat about firewall management, but I guess it's always possible it's blocking the binary data in the cURL request while letting the XML and text values through. HTH

The following will read the image from Filmaker and write a local copy on the fly. I'm assuming image.php is a standard "container bridge" file and RecID is the only parm required to produce a single image from the database. Still, depending on your requirements this could become more trouble than it's worth (see below). $imgpath = "http://server/path/image.php?RecID=" .$_GET['RecID']; $img_h = curl_init($imgpath); curl_setopt($img_h, CURLOPT_RETURNTRANSFER, true); $imgString = curl_exec($img_h); $info = curl_getinfo($img_h); $fh = fopen("./img/img" . $_GET['RecID'] . ".jpg", "w" ); fwrite($fh, $imgString); curl_close($img_h); fclose($fh) The first potential problems that come to mind are large images and several simultaneous hits, but that could hose your PDF gen as well. As coded it only works with jpegs you can parse out the mime type included in $info['content_type'] to alter the file extension if you want to open it up other image file types, but given that FMP will take just about anything you may still run into trouble.

I would highly suggest using another convention. A period is generally used in SQL to separate database names from table names from field names in queries. e.g. SELECT table1.name, table2.name FROM table1 JOIN table2 ON table1.ID = table2.table1_ID You can always get around it by using text delimiters in your query (e.g. table1.`Contact.name` for MySQL; table1.[Contact.name] for SQL server) but that can be a real PIA to maintain and/or read and is a recipe for bugs down the road.

This is your problem. $fieldValueArray = explode(" ", str_replace("n"," ", $fieldvalue)); You're replacing FMP's newline value delimiter with a space and then telling php to use spaces as the delimiter for setting up the array. Why not just use the following? $fieldValueArray = explode("n",$fieldvalue);

interesting because the code I posted worked for me with the following setup. PHP running on a LAMP server and FMSA10 running on W2K3 IIS What configuration are you using?? edited to add - Whenever text doesn't appear to function correctly I start thinking it may be an encoding issue. Try adding the following to the header of the page that generates the data you could also try $currentRecord->setField('tActivity_Log', $text . chr(13));

$currentRecord->setField('tActivity_Log', $text . "nr");

The API uses PHP's built in XML Parser to parse the result of the cURL request it sent to Filemaker's XML feed. So I doubt that's the hang up. Still given that every lag I've run into has been fixed by reducing the amount of XML returned by Filemaker Server this is interesting. If you get it figured out please post back. Generally speaking I've found that I get the best results from the API by grabbing the absolute minimum of data possible on page load. I then use Ajax to pick up each individual piece as I need it, often creating a specific layout to maximize the efficiency of each call.

assuming eventRecordID is Filemaker's internal record id for the event table (as opposed to a field in the table which is set up as the Primary Key), you can use $record = $fm->getRecordById('event_layout', $_GET['eventRecordID']); /*error checking is always helpful*/ if($fm->isError($record)){ echo "ERROR( " . $record->getCode() . ") " . $record->getMessage(); exit(); } to get the record otherwise you'll have to run the search $req = $fm->newFindCommand("event_layout"); $req->addFindCriterion("eventRecordID",$_GET['eventRecordID']); $result = $req->execute(); if($fm->isError($req)){ echo "ERROR( " . $req->getCode() . ") " . $req->getMessage(); exit(); } $records = $req->getRecords(); /*assuming search is on Primary Key i.e. will alway return a single record. Just grab the first and only value in the array*/ $rec = $records[0];

Trying to learn PHP by looking at Site Assistant's code is like trying to learn English by listening to G W Bush. Scrap the site assistant; look at the PHP API example included with FMS; and use that as a template to build the pages you need. It will likely be faster than chasing down all problems you'll run into as you tweak the SA code.

The attached works for me with: FM Server Version 10.0.1.64 on IIS / Win2K3 PHP code on LAMP My general feeling on tweaking the SA code is that you'll spend more time fixing unintended consequences than building what you need from scratch. My guess is that's what's at play here. testNotEmptyValid.zip

Dough! Well the only possibly useful piece of data I can add is that the PHP API communicates with Filemaker via a cURL request to the XML feed. You're most likely on the right track with it being an IIS encoding issue. If it's an option you could try putting the Site Assistant code on an Apache server and see what happens