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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
