Yes, and also clear the cache. There's a utility provided under the administration pages (Performance) that will clear these cache tables for you, so you shouldn't need to manually delete the tables.
Also: If you copy the files, copy the database and feel comfortable editing the settings.php file, there is no real need to go through the installation process in the qa environment.
Dave
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Steve Edwards Sent: Friday, August 05, 2011 1:21 PM To: support@drupal.org Subject: Re: [support] importing database into qa environment collides withproduction
Check that value for $base_url in settings.php. It could be still pointing to the production URL.
On Aug 5, 2011, at 1:11 PM, Tim Dunphy wrote:
Hello Drupal,
We have a few drupal based sites here in the office and I ran into a
problem recently when I was asked to setup one of the production sites in a qa environment. Basically the steps I took were to copy the files from apache document root of the production site to the right location on the qa web serer, run the install as usual and then import the production database to the qa instance afterward.
So far so good. After tweaking the files a bit, the production site
comes up in qa and I am able to log into the qa instance using drupal accounts from production. However there was an unexpected result. When I started clicking on the links from the QA installation it would point me to pages from production. That part of it was not entirely unexpected I guess but the problem was that after I started clicking on the links that pointed to production, CSS on the production site broke. When I say that it 'broke' what I mean is the CSS formatting was lost on all of the pages. I was able to fix the problem in production by clearing the cache from the drupal interface on the production side. Just to be safe, I dropped the database on the qa instance to make sure that it wouldn't cause any more issues in production.
So from that it seems that importing the database provided some
resources to the qa instance that were being shared with production. I was hoping to get an opinion on what those resources might be so that I can perhaps clear the table(s) before making another attempt to import the production database into qa.
I think what may work is to delete the contents of certain tables with
a DELETE * FROM table. Based on some readings I've done into the issue I would think that cache, session and watchdog may be part of the problem. But before I proceeded I would like to get your opinion on whether this might help and perhaps suggest some other tables that could be causing the problem.
Thanks!! Tim -- [ Drupal support list | http://lists.drupal.org/ ]