[support] importing database into qa environment collides withproduction

Metzler, David metzlerd at evergreen.edu
Fri Aug 5 20:31:05 UTC 2011


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 at drupal.org [mailto:support-bounces at drupal.org] On
Behalf Of Steve Edwards
Sent: Friday, August 05, 2011 1:21 PM
To: support at 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/ ]

-- 
[ Drupal support list | http://lists.drupal.org/ ]


More information about the support mailing list