I think if I ask for all the records that meet certain criteria and zero are returned because there are none, then this is not an error condition.

I end up having to probe the error object to check the message, which I find to be a bad practice given the tight coupling.

Can we not just rely on getFetchCount() to figure out if there were no results returned?

No...

This throws an error just like FileMaker throws an error when no records are found. It's easy enough to check:

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

    if( $result->getCode() == 401 ) {

         /*Do what you want if no records are found.*/

    } else {

         /*Do what you want if some other error occured.*/

    }

}else{

         /*Do what you want if no error occured*/

}

Think of it this way: no error = records returned, error = no records returned.

While I agree that an empty result set should not be an error, it is an exception that should be handled. Your average user isn't going to see an empty set and think "oh no records met that criterion". They're going to think "WTF?". The Filemaker client doesn't split exceptions into say: notices, warnings, and errors. It just does errors.

So just think error = exception and it should make more sense.

Genx, I don't think you understood my post very well. I guess a lot of people must write to these forums who are not programmers.

My issue is not technical. It's philosophical. I know how to construct an if statement. LOL

If my query is valid, and it executes without incident, how is that an error? I gleaned from the other poster's comment that this mirrors how filemaker works, but is different than most standard database query languages.

I don't like to refer to a particular specific error code in my error handling, because it's a code smell.

I suspect that most developers with this api have similarly crufty solutions to the one you've produced for us here deployed in their applications.

Doesn't that fact in and of itself seem to indicate this was a poor design choice?

1) FileMaker is not SQL

2) FileMaker is not a programming language

3) The developers were being consistant

4) Perhaps consistant with bad choices but this is what is defined as an error in FileMaker and hence what they've defined as an error in the API

5) If you don't like it, write a function or overload the class.

6) This API is one of the better implementations i've seen of ORM based on any db in PHP

7) It is admitidly slightly different, but I guess they had the idea that you have two scenarios:

a) You got the result you wanted and have some data to output.

You didn't get the records you wanted.

Genx,

They are in fact not being consistant. In FM itself, when a script step executes successfully, it generates error code 0. Same with CWP with XSLT(generates 0 when all is well).

I would be content if filemaker would add 0 as an error code to the PHP API - like the above examples so that a developer could do

$result->getCode() == 0

when all is well.

okay

1) Try perform a search in a script in FM, and then use Get(LastError) and see what comes up...

2) Nothings perfect ... Just deal with it. Add getCode to the FileMaker result class and just have it return 0.

How did you guys know about getCode()? I don't see it in any of the getting started guides or in my Sams PHP for FM book. I'm also using the FMStudio plugin for dreamweaver which color codes FM PHP API code. getCode() doesn't change color the way getMessage() and everything else does.

Edited June 29, 200817 yr by Guest

Filemaker_Error extends PEAR_Error; getCode() is a PEAR_Error function