CiviCRM Community Forums (archive)

I'm looking to extract contacts from the civi database using the API. So I am using code like this;

$params = array( 'version'  => 3 );
$result = civicrm_api( 'Contact' , ' get' , $params );

However, what I actually need to do is extract contacts from civi, only when they have an image (logo) uploaded to their record (held in the image_URL field). What I am really looking for is achieving the equivalent of a sql statement 

WHERE image_URL<>''

However, I dont think anything like that exists in the API but I noticed that there is a LIKE operator, so I tried this (all logo files will contain the word 'logo')


$params = array( 'version'  => 3, 'image_URL' => array('LIKE'=>'%logo%') );
$result = civicrm_api( 'Contact' , ' get' , $params );

This produces this error;

Array ( [is_error] => 1 [error_message] => A fatal error was triggered )

Is this possible and if so, how might I approach it? Have I made a fundamental error? I don't really want to extract all contacts (running into the 10,000's) and then filter out only those with a logo uploaded so need to find a way to do it. I guess I could just query the contacts table directly but there is likely to be other things in the civi database I need to extract in a similar way so using the API seems the right thing to do.

Thanks in advance for any help

Al.

The api supports more than just the LIKE operator. Take a look at the new api explorer in 4.5, it exposes them for you: http://drupal.sandbox.civicrm.org/civicrm/api/explorer
However, the contact api is a bit funky. Unlike most other apis it always assumes LIKE rather than = as the operator, so you might just try doing it like $params = array( 'version'  => 3, 'image_URL' => '%logo%' );
PS if you use civicrm_api3 then you can leave off the version param.

This commit https://github.com/fuzionnz/civicrm-core/commit/e2a7ba438e931dd708ff19a441689f9a0c42fb38 which is in 4.5 or in our fuzion 4.4.6 release extends the support for LIKE in contact query - although I have no idea if it covers the field you are looking at - it possibly does if you were hitting the fatal since it injects the attempt to resolve with SQL operators right before the fatal