DannyS

Thanks Jack You are right, that's where the log and reference files are. No big deal as I can delete them there when I need to. Not sure why it doesn't want to put them back in the admin directory when it can follow the path to Sitemonitor in the cron job. The admin directory was renamed so maybe that's the problem. I will test it with a new dummy admin directory and see if it puts them there.

Thanks Jack I can't access the servers home but I will see if through the Sitemonitor configuration it will delete the reference file in 1 day. The cron job path finds Sitemonitor OK, but the call to PHP is 5 directories deep. I will try calling Sitemonitor as a URL and see if then it behaves properly.

It seems that running Sitemonitor from admin and running it from a cron job are using different reference files. Has anyone else seen this as I get different results as the cron job compares to an earlier snapshot of the files and I have no idea where it has stored that reference file as it's not the one in admin. Could it be in a cache somewhere?

I think it's something to do with a missing LOCALECODE parameter. I'm trying to track it down also as mine is reverting to Thai where we are based.

Mark Well done - great contribution. Regarding the earlyMYSQL versions, pre- version 4.0, the problem is it needs the WHERE and ORDER by is not recognised. I know nothing about MYSQL syntax but the following seems to work. $del_query = "DELETE from supertracker WHERE tracking_id>0 LIMIT " . $rows_to_delete; It seems to start from the lowest tracking_id this way. A quick question - when using shared SSL we see two records. The customer entering the non-SSL part carrying the real refferer and then the customer entering the SSL part and the refferer is the non-SSL URL. Anyway these records could be joined, especially after a sale. Danny