On Sat, Feb 13, 2010 at 3:46 PM, Joseph Thayne <webad...@thaynefam.org> wrote:
> In order to make this as "sql server independent" as possible, the first
> thing you need to do is not use extended inserts as that is a MySQL
> capability.  If you are insistent on using the extended inserts, then look
> at the mysql_info() function.  That will return the number of rows inserted,
> etc. on the last query.

But as previous posters had pointed out (thanks) i can't see which rows failed.
As i'm dealing with 3rd-party data, that's an issue.

I also didn't know it was mysql-specific, that multi-insert..

And i tried looking up the sql-standard docs, only to find that they
cost over 200 euro per
part (14 parts).
I've sent angry emails to ansi.org and iso.org (commercial lamers
operating under .org, yuck), about how cool a business model that
charges a percentage of profits per implementation would be, instead
of charging high prices up-front for a potentially bad/complicated
piece of spec.

But back to the problem at hand; it looks like i'll have to forget
about using 100s of threads for my newsscraper at the same time, and
settle for a few dozen instead.
Then i can just do single inserts (per hit) and retrieve the last_insert_id().

One question remains: it is probably not (concurrently-)safe to do a
sql-insert from php and then a last_insert_id() also from php..?
I still have to build a stored procedure to do-the-inserting and
return the last_insert_id()?

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to