[CMX_CMGSCCC]

Originally Posted by Gwynar

CMX_CMGSCCC,

Just out of curiousity, is there any reason why you don't have an expire table that holds information on all items that have expiration dates? And then running a vbcron once every 24-hours set everything back?

Seems like that would cause fewer corruption headaches with the expiration field in the user table. And this would also allow items to expire without the user having to log in.

I think this method would be a lot more efficient than what you're currently using (although I suppose it would require an extra ADD query when a user makes a purchase).

The reason was, I didnt want to do any Cron Tasks at first, but now I have done 3, I guess a 4th one couldnt hurt...

I have finally fixed the problem that some users had with expiring options in the v1.2.0 release. In reality, an expired options table method would be much more effective because even if the item somehow got removed from a user's history, it would still be in the table of options to expire.

The main problem with expiring options is, some options can not expire at all, and/or require longer processes to expire. For example, if u wanted a username to expire and go back to the old username, that would create about 6 more queries to change per username that expired due to the fact it has to change the username in posts, thread, etc...

The current expiring field now makes it expire based on when the user is active and it calls the estore.php. The reason that is a good thing is, if there are "custom expiring fields", it would be easier to handle in the estore.php file instead of a cron task job...

So all in all, I really dont know which one is the "best" method to use. Each have their pro's and con's. And if a cron task is used, it would only be able to handle the "basic" expiring fields and as far as I know, cron tasks are basically ran soon as someone access the forums on a given time? It's not running the tasks like a real cron job is it? Meaning for example, if u had to expire 100 user options, it would do 100 queries for some user who happens to view it at the time it needs to run the cron task?

Correct me if I'm wrong about the scheduled task system as I havent taken the time to research it to see how it actually runs them. I'm just assuming it doesnt have 'root' access to be able to start a REAL cron job.

-CMX