Welcome to Forums Sign in | Join | Help | Forums
in Search


API - Searching without Invoking the Search Screen etc

Last post 06-26-2006 5:38 AM by David Zeidman. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • 06-22-2006 11:12 PM

    • Chris Thomson
    • Top 500 Contributor
    • Posts 37
    • Organization: Victoria University of Wellington
    • Products:  The Raiser's Edge

    API - Searching without Invoking the Search Screen etc

    Hi, What we want to do is to execute a search by specifying the search parameters programmatically, for example • Search Type = SEARCH_CONSTITUENT • First Name “Dean *” • Post Code = “6003” and to have returned a set of records (i.e. QuerySet, Collection, Array etc), and not have any dialog boxes or forms appear. I have not been able to find anywhere within the API any reference to where this could be done. Any suggestions Thanks Chris. [Email Removed] [Email Removed] p.s. Am developing code in C#
  • 06-22-2006 11:44 PM In reply to

    • Peter Falconer
    • Top 500 Contributor
    • Posts 36
    • Organization: Oxfam Australia
    • Products:  The Raiser's Edge

    API - Searching without Invoking the Search Screen etc

    The following is an example for gifts, but you can do the same for Constituents Set oGifts = New CGifts strFilter = "GIFT_STATUS = 2 and TYPE = 30" oGifts.Init REApplication.SessionContext, tvf_Gift_CustomWhereClause, strFilter where the filter is a standard where clause (without the where) For constituents you end up with a CRecords collection
  • 06-26-2006 5:38 AM In reply to

    • David Zeidman
    • Top 25 Contributor
    • User Since: 2002
    • Posts 326
    • Organization: Zeidman Development
    • Products:  Blackbaud Direct Marketing, Blackbaud Enterprise CRM, The Information Edge, The Raiser's Edge

    API - Searching without Invoking the Search Screen etc

    This solution may work in general but not for the two areas that Chris wants. The where clause only works on the db table where the main object is referenced i.e. in the case of the constituent object the where clause only works on the RECORDS table. This means that the first name is accessible in this way but the post code is not. There are two ways around this. 1. Use the where clause with a subselect. e.g. FIRST_NAME = 'David' and ID = (SELECT CONSTIT_ADDRESS.CONSTIT_ID FROM CONSTIT_ADDRESS, ADDRESS WHERE CONSTIT_ADDRESS.ADDRESS_ID=ADDRESS.ID AND ADDRESS.POST_CODE='XX1 1XX') This works but it may be slow. 2. If you have RE:Open then use IBBUtilityCode (an interface implemented by REServices). This contains the function CreateDisconnectedADORecordset. It returns an ADO record set based on a SQL query that you give it. With this you can write the SQL exactly how you want in order to return a record set of results e.g. SELECT RECORDS.ID FROM RECORDS,CONSTIT_ADDRESS,ADDRESS WHERE FIRST_NAME = 'David' and ID = CONSTIT_ADDRESS.CONSTIT_ID AND CONSTIT_ADDRESS.ADDRESS_ID=ADDRESS.ID AND ADDRESS.POST_CODE='XX1 1XX') To use the CreateDisconnectedADORecordset you need to supply it with your RE:OPEN user name and password that is set up when you first use RE:OPEN. You can alternatively create a database user that has DB Owner rights and use those credentials instead. Hope this helps. Let me know if you need any more help David Zeidman Development http://www.zeidman.info
    David Zeidman
    Zeidman Development
    http://www.zeidman.info

    Check out my RE API blog
    http://www.re-decoded.com
Page 1 of 1 (3 items)