“We are seeing some heavy querying from a RETS vendor in NEREN: LoginName: gar0608

edit

I beleive the query you are refering to is a data query that runs every 15 minutes and is based on the last time stamp that it ran. This is how we run our incrementals through out the day. I am not sure why we would need an offset as there were probably not 2500 changes in a 15 - 20 minute time frame.

You may not need to use it. But if you return the data fields in your incremental, you wouldn't need to do the corresponding batch ones you do after that.

Just to add to this. Currently, I am running a full data download and have made sure that the process is pulling 2000 listings at a time for example. RE_! has just over 18000 listings, our process will pull all ids for the 18,000 and will pull batchs of 2000 at a time. I would be suprised if this is putting undo stress on the rets server, but please confirm as I am testing this currently.

It doesn't seem to be too bad. But I would suggest that if you do full pulls, you try to do it outside of normal business day hours, and stick to incremental pulls during the day. Also I noticed that you are pulling a lot of data for open house searches. Instead of pulling them by the open house key field. You are pulling by listing key which returns OH records for the listing.

It also looks like you are doing a second search attempt with the same query if no records are found on the first one. BF_6 for example I see two queries with: (L_StatusCatID=|1,3),(L_Last_Photo_updt=2018-06-15T16:11:01Z+),(L_PictureCount=0+) right in a row.

can you send me this so I can see it. The way the process is written that should only send that query once to obtain the listing ids with photos that have been modified after that timestamp. please send it to sgaraux@deltagroup.com. Thank you.

Full pulls only happen in the off hours. The only reason I was attempting a full pull was for the testing I was doing.

I also have a process for the photos that will not allow one to run on top of another photo process already running. So if our incremental photo process is currently running and another incremental photo process tries to kick off it will not run.

I see what you mean about the openhouse data. I made modifications to use the OH_UniqueID and also saw where someone here was doing some testing and pulling older openhouse data that we dont need. So I have made adjustments to that and the openhouse pull should look considerably better.

Can you also make sure to call the Logout on the session when you are finished with pulls. It will help keep from cluttering up our connections and free up some system resources. They eventually get closed out after a couple of hours. But it is better to close them when you are finished using them.

I saw the openhouse request come through twice (duplicated) for each class. Here is an example: Resource: OpenHouse Type: RE_1 Request: (OH_StartDate=2018-06-15+) Select: OH_UniqueID But I didn't see any requests pulling the OH data by the ID's that were returned.

let me check it.

Openhouse data should look better.

Openhouse searches look much better now. Did you look into adding Logout?

I will look at that does everything else seem to be within reason now?

Yes it does seem to be looking much better now.

okay thank you. I will check on the logout portion of the code and make sure we have it working so it is not leaving sessions open.

Were you able to check into calling Logout? I'm still not seeing any Logout transactions in the RETS logs.

Still not seeing any Logout calls in your requests. If by chance you were using PHRETS, the Logout function is called Disconnect().

I see the Logout calls now. Thank you.