Ask Your Question

Revision history [back]

Possible Reasons: * Batching normally you can pull a certain amount of records in a single search. Normal limit is 2500. To get them all when this happens you would need to use Offset/Limit functionality and pull them all using sequential search batches. * Profile filtering on the class. The MLS may limit the data for certain classes within the profile. * Profile field selections. A field could be disabled in the profile in which case it returns the data as blank and searching the field would fail. * An agent or office can go inactive for a while or something change that effects the filtering such as a short name value. Normally the key field value for a record doesn't change. Such as in this case, O_OfficeID. If your profile has access to the Office resource use it instead of ActiveOffice because it should return it if it is still in the system. * There can be other changes such as an office's board selection being changed when the profile has board filtering on it. * To work around some of these issues you can normally get a list of all the O_OfficeID values maybe once a day, then compare to your local set to find any missing. And do incremental checks by O_UpdateDate at other times during the day.

Possible Reasons: * Batching normally you can pull a certain amount of records in a single search. Normal limit is 2500. To get them all records when this happens you would need to use Offset/Limit functionality and pull them all using sequential search batches. batches. For example: Offset=1, Limit=2500; Offset=2501, Limit=2500; etc. * Profile filtering on the particular resources and class. The MLS may limit the accessable data for certain classes within the profile. * Profile field selections. A field could be disabled in the profile in which case it returns the data as blank and searching the field would fail. * An agent or office can go inactive for a while or something change that effects the filtering such as a short name value. Normally the key field value for a record doesn't change. Such as in this case, O_OfficeID. If you are storing data locally, I would use the keyfield value as the unique identifier. If your profile has access to the Office resource use it instead of ActiveOffice because it should return it if the office as long as it is still in the system. * There can be other changes such as an office's board selection being changed when the profile has board filtering on it. it. Sometimes the data returned is limited by office or Main Office. * To work around some of these issues you can normally get a list of all the O_OfficeID values maybe once a day, then compare to your local set to find any that are missing. And Then just do incremental checks by O_UpdateDate at a few other times during the day.day. * Another thing is if your code pulling offices isn't handling errors properly and removes the offices instead of detecting there was an error during the pull and retrying later.