On Wed, Jan 21, 2009 at 7:07 PM, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 2009-01-21 at 18:52 -0500, Eric Butera wrote: >> On Wed, Jan 21, 2009 at 6:37 PM, Jochem Maas <jochem@xxxxxxxxxxxxx> wrote: >> > Chris schreef: >> >> >> >>>>> Yea if you're only targeting 1 db, then why not use that class? At >> >>>>> least then there's the php manual to figure out what something does. >> >>>> Because then to add query logging for the whole app, you just need to >> >>>> put it >> >>>> in the class :) >> >>>> >> >>>> (I've done that before to check what's being run and where from, >> >>>> comes in >> >>>> very handy). >> >>>> >> >> >> >>> >> >>> That's done by tail -f /var/log/mysql/query.log. :D >> >> >> >> That won't tell you where a query comes from ;) Add a debug_backtrace >> >> into the class to also pinpoint where the query was called from. >> >> Complicated queries built on variables (or even just long queries built >> >> over multiple lines) will be hard to find just by looking at the mysql >> >> query log. >> >> >> > >> > besides on shared hosting that log is often turned off even if you can get at it. >> > >> > >> >> That's why I set up a local dev environment. If something is wrong, >> just grab a db dump & figure it out locally. That way I can do >> whatever I need to really try out what the issue is and the best way >> to resolve it. >> >> Just merely saying how I develop. Whatever gets it done is the real way. :) >> > A DB dump won't always tell you where the problem lies. With proper > logging, you can use the DB dump to work out what went wrong precisely. > > > Ash > www.ashleysheridan.co.uk > > I meant grab a remote db dump, import it locally, reproduce the issue locally, look at local query log, fix. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
