Personally I would suggest modifying the database calls so the stats code is inserted into a separate database. Then you can use the tool of your choice to either copy them to the farcry database for admin area reporting, or use an external reporting tool directly on the separate database.
This is a fairly common approach for auditing systems where youy audit will contain a large amount of data, but you don't want the auditing process to interfere much with normal server operations. Spike -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk Do you cfeclipse? http://cfeclipse.tigris.org >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf >Of Tom Cornilliac >Sent: Tuesday, June 15, 2004 9:21 AM >To: FarCry Developers >Subject: [farcry-dev] Stats Logging > >As our stats table grows beyond several million records I'm starting to >seriously question the wisdom of direct inserts into the stats table. >The dangers of such a tight coupling are glaringly apparent when we run >reports or Db maintenance on the stats table and the site slows to a >sloooooooooooow crawl as the inserts compete for Db locks. > >So here's my question gang. Has anyone else experienced this >problem? If >so, what have you done about it? My first thought is to log to a text >file and then BCP the data into Stats on a short schedule. > >~tom > >--- >You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] >To unsubscribe send a blank email to >[EMAIL PROTECTED] >Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
