Jump to content

Newbie question


carel16

This topic is 4625 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

Hi everyone,

I am coming over from the php odbc world. I am hoping that the API will help me to overcome some of the limitations I have been encountering. The most important one being the 256 character return limit.

So my filemaker friend recommended the API and even shared some resources with me. I have 2 servers to replicate my working environment - a filemaker advanced server 10 and a windows 2003 server running iis. In addition my friend attended the developers conference in San Diego and brought back some demo files that one of the presenters gave out.

Everything from the demo works great! The only problem is when I tried to copy over a snapshot of our live data. When I tried to query a small table and return 4 fields into an array I got no errors and the table got built but every cell was empty. I can tell that it got back the correct number of rows but looking at the source I see no data.

Has anyone else ever experienced this issue? What troubleshooting steps should I perform? Thanks!

Link to comment
Share on other sites

  • Newbies

// load the FileMaker PHP API libraries require_once('FileMaker.php');  // initiate the connection to FMS $fm = new FileMaker('dev_db', '172.10.192.32'); $fm->setProperty('username', 'php'); $fm->setProperty('password', 'php');  // using the 'connection' that we've just established // create a command to find all records based on a specific layout $cmd = $fm->newFindAllCommand('Menu');  // excute the command and direct the result of that to a variable $result = $cmd->execute(); // check and see if there was an error in the execution if(FileMaker::isError($result)) {  	// in the real world you'd do more than just chuck an error message on the screen 	// the 'code' below will be a standard FM error code 	die('

An error occured: '.$result->code.' ('.$result->message.')'); } else { 	// get the records which resulted from the find 	$records = $result->getRecords(); }

Can't get the tag to recognize carriage returns. This is frustrating.

Link to comment
Share on other sites

  • Newbies


// load the FileMaker PHP API libraries

require_once('FileMaker.php');



// initiate the connection to FMS

$fm = new FileMaker('dev_db', '172.10.192.32');

$fm->setProperty('username', 'php');

$fm->setProperty('password', 'php');



// using the 'connection' that we've just established

// create a command to find all records based on a specific layout

$cmd = $fm->newFindAllCommand('Menu');



// excute the command and direct the result of that to a variable

$result = $cmd->execute();

// check and see if there was an error in the execution

if(FileMaker::isError($result)) {

  // in the real world you'd do more than just chuck an error message on the screen

  // the 'code' below will be a standard FM error code

  die('<p>An error occured: '.$result->code.' ('.$result->message.')</p>');

} else {

  // get the records which resulted from the find

  $records = $result->getRecords();

}



Firefox seems to work better, huh?



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

<title>Our website</title>

  <link rel="stylesheet" type="text/css" media="all" href="assets/css/style.css" />

</head>

<body>

  <div id="container">

   <div id="header">

    <div id="logo" class="col1"><h1><a href="/">Logo</a></h1></div>

    <div id="environment"></div>

   </div>

   <div id="mainBody">

    <div id="inner">

	 <div id="leftColumn" class="col1">

	  <h2>Menu</h2>

	  <div id="menu">

   

	  </div>

	 </div>

	 <div id="rightColumn" class="col2">

	  <div id="title"><h1>Records</h1></div>

	  <div id="content">

	   <table>

	    <thead>

		 <tr>

		  <th>Menu Record Tag</th>

		  <th>Menu Record Sort</th>

		 </tr>

	    </thead>

	    <tbody>

		 <?php foreach($records as $record) { ?>

		 <tr>

		  <td><?php echo $record->getField('RecordTag')?></td>

		  <td><?php echo $record->getField('RecordSort')?></td>

		 </tr>

		 <?php } ?>

	    </tbody>

	   </table>

	  </div>

	 </div>

    </div>

   </div>

   <div id="footer" class="clear">Footer</div>

  </div>

  <div id="panel"> 

	 <div id="dialog" class="window">

	  <div id="dialogBar"><div class="ui-state-default ui-corner-all floatRight margin2px hand" onclick="closeMask();"><span class="ui-icon ui-icon-closethick">close</span></div></div>

	  <div id="dialogContent"></div>

	 </div>

	  <div id="mask"></div> 

  </div>

</body>

</html>

I don't know if the posting tools are blocked by IE but using Firefox just made my life easier!

Link to comment
Share on other sites

  • Newbies

@doughemi - Thanks for the kick in the seat. I was referring to the tables not the layouts. I've got to wrap my head around that one. Do you know what the reasoning is? It would be wonderful to refer to the table rather than the layout. Unless, you are capable of leveraging some of the filemaker layout features such as calculations and such. Maybe I just answered my own question...

Thanks again!

Link to comment
Share on other sites

using Firefox just made my life easier!

That's a universal constant! :laugh:

Do you know what the reasoning is?

There's just a whole lot less data in a layout object than a table object. You can create specific layouts for php with only the fields you are interested in, and significantly (sometimes hugely) reduce the overhead.

Link to comment
Share on other sites

The advantage of layouts as opposed to tables:

  • you can return subsets of data in table by creating layouts with just specific fields on them. this will allow you to return larger sets of records with less overhead (resulting both from smaller data size and prevention of unnecessary unstored calculations)
  • layouts are relationally aware - any portals that you have on your layout are accessible via a method on the record object (getRelatedSet()) without needing to perform separate queries to artificially reconstruct the relationships as you'd have to with ODBC. This has very large convenience and speed benefits.
  • the API has a fairly critical bottleneck - the length of time it takes to execute a single API query is normally acceptable (depending on where the web server is in relation to the FileMaker server). If you are adding or modifying a complex object with significant amounts of related data, a single API call which adds and modifies all the records via the portals will execute exponentially (depending on how many related entities you have) faster than individual API calls for each and every record and related record.
  • Layouts as context based data access methods are a constant concept in FileMaker and have been for a while - the API exposes this and essentially allows web developers to work well with FileMaker developers without needing to understand the nature of the calculations or relationships ... just that they exist (at this stage, these two groups [filemaker developers and web developers] are largely the same - if FileMaker ever gets their act together and improves the quality and speed of their web engine and the speed and reliability of their storage / server engine, this may change ... that being said i don't see too much hope for that any time soon despite the them of this years developer gathering supposedly being about "the cloud")

Link to comment
Share on other sites

This topic is 4625 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.