I was finding that whenever I batch "update now" on the listings, it would always create new nodes instead of updating existing ones. I am connecting to an Interealty RETS server which I hear is different from other servers by having letters in the MLS number, for example "V123456".

Looking at the pirets_class_update_batch_update function, seems that this line of code was incompatible with alphanumeric mls numbers:

$prop = array_map('intval', $prop);

I would imagine that it would be storing a "0" value for all the MLS numbers, hence no update only add. I commented out this line for now and seems to be working.

Comments

Garrett Albright’s picture

Interealty seems to have various issues. See this forum post too.

Allowing letters in the MLS number (…ugh) won't fix everything, because another quirk of Interalty is that images aren't fetched by using the MLS number as they are with every other system I know of.

It's gonna take some work to get PIRETS working with Interealty, unfortunately. Fortunately, nothing in that work seems impossible.

EDIT: Roffle… I noticed that you yourself started that thread I linked to…

scott_earnest’s picture

Let me know if you can think of other places in the code where alphanumeric MLS numbers may pose a problem.

Thanks Garrett.

Anonymous’s picture

Same problem here. I'm connecting to a Solid Earth RETS server. The MLS_ACCT, LA_CODE, & LO_CODE as far as i can see all start with "B" then numeric after that. I commented out the line mentioned above and it seems to fix the issue.

When I do a manual update, I seem to always have the same response. So I'm looking for the reason why the same 128 get updated and other 122 are left unchanged?

Class update for RES completed. 0 created, 128 updated, 0 deleted, 122 unchanged.

Garrett Albright’s picture

If no records are being created unnecessarily upon update, then it is not related to this issue.

As for why some records always update… I don't know. I've seen it happen here and there as well. Something about them is changing on every update - I suspect the server is putting a time in a field somewhere, either the current time or a "time ago" value. Either way, as it's a much less dire issue than new records being created or records being prematurely deleted, I haven't sweated over it too much.