Nathan Nobbe wrote: > On 11/5/07, Jon Westcot <jon@xxxxxxxxxxx> wrote: >> Hi Nathan: >> >> No, I'm not familiar with Ajax. Where can I read up on it? More >> important, how can I find out if Ajax is implemented on the server? Or is >> it something I can add myself? >> > although it might sound cool - using ajax to issue multiple requests is NOT the correct solution. your merely moving the goalposts (what happens when user moves off the page just as the third ajax request is made?) your looking to run a series of inserts whilst garanteeing that they are not interrupted. Dan Brown (the nice guy on this list, not the twat that wrote the 'daVinci Code') suggests a *much* better way to go- namely using a CLI script. the fun part is getting a button push on an admin page to somehow initiate the CLI script. one way of doing this could be to have a 'job' table in your database to which 'jobs' are inserted (e.g. 'do my 30000 record import') and that your [CLI] script checks the database to see if it should start a 'job' and just exit if it does not need to do so ... lastly in order to have the [CLI] script regularly check if it needs to do something you can use cron to schedule that the script runs at regular intervals (e.g. every 15 minutes) many ways to skin this cat - my guess is all the decent ways of doing it will involve a CLI script probably in conjunction with a cronjob. > > if you arent familiar w/ ajax, no worries; the main concept in my suggestion > is > sending a number of requests rather than a single request. that way you can > execute a fraction of the queries on each request. this will ensure that > you dont > hit the maximum execution time. > > a purely php approach would be using the header() function. so, on each > request > where the queries are not yet complete, your script sends a header tag to > the browser > which will immediately invoke another request back on the same script. > once all the queries have been executed dont invoke the header() function, > that would > essentially be the results page. > the reason i prefer ajax over this approach is that the page will be > blanking out a lot, > basically on every request. but it would defiantly work. > > also, ajax is mainly a client side technology; where http requests are sent > to the > server without incurring a ful page refresh. you need nothing extra on the > server. > ive been using prototype, a javascript toolkit which has some nice support > for ajax. > if you want to check it out, heres an article on ajax using prototype: > http://www.prototypejs.org/learn/introduction-to-ajax > > -nathan > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php