[wp-hackers] preventing the duplicate wp_insert_post effect

[Haluk Karamete]

This is all part of a migration routine I wrote where a while loop
goes thru 15,000 records from an ms-sql table and converts each record
into a post_data array to be fed into the wp_insert_post API.
Technically, since I'm dealing with 15000 recs in ms-sql, I should end
up with 15000 posts in a fresh installed wp_posts table. Right? In my
case, I sometimes get 16000, sometimes 290000. It's never the same.
Everytime is different. I'm almost to the point to re-write the code.
But if the culprit itself the wp_insert_post and some internal wp
process or wordpress cache that I do not know of or mysql server
config and or and or and or... , even the new approach won't work.

After some research, I've come to learm I'm not alone on this. But
from what I read, I could not get a wrapper around it.

As I said above, I create the posts going thru a while loop.

Since the process takes a long time, I had to build a custom time-out
module. As the code goes thru the iterations of the while loop, it
marks its process into a time_out table, and siince I got a watch dog
page that's running in an iframe to keep an eye on the time_out
table's progress, even if the bottom frame ( the one that handles the
ms-sql to wp_posts process ) times out, I know from what record to
kick start the process.

This way I do not have to sit in front of the computer to keep
clicking on 'continue'. link.

Well, this trick works on all of my implementations that are severed
by timeouts . I eventually end up getting the whole table is processed
and the watch dog iframe stops refreshing when the number of records
to be processed is equal to the number of records that have been
processed in the last instance. So the time-out module works perfectly
except....

Only and only when the destination table is wp_posts and when the the
wp_insert_post API is involved, I get a problem.

After the first time-out, things start getting hay-wired.