[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Error when upgrading 1.2 db to 1.3 db
- Subject: Re: Error when upgrading 1.2 db to 1.3 db
- From: Chris Travers <..hidden..>
- Date: Wed, 11 Jan 2012 02:38:03 -0800
On Wed, Jan 11, 2012 at 2:29 AM, Nigel Titley <..hidden..> wrote:
> On 11/01/2012 06:14, Chris Travers wrote:
>> On Tue, Jan 10, 2012 at 2:56 PM, Nigel Titley<..hidden..> wrote:
>>> On 10/01/12 22:02, Erik Huelsmann wrote:
>>>> Hi Nigel,
>>>>> I'm about to add a header at the start, dump a new test copy of the
>>>>> database and try again.
>>>> That should do it. Please let us know about your outcome.
>>> OK, I'm now getting a little further on
>>> psql:1.2-1.3-upgrade.sql:38: ERROR: null value in column "country_id"
>>> violates not-null constraint
>>> Looking at the upgrade script this seems to be caused by my using
>>> "United Kingdom" rather than "UK" for the default country.
>>> Fixing this then takes us a lot further on to
>>> psql:1.2-1.3-upgrade.sql:157: ERROR: duplicate key value violates
>>> unique constraint "eca_to_contact_pkey"
>>> and here I get a bit bogged down in the SQL and it would help to have a
>>> pointer to look for.
>> You have a contact where you have a duplicate email address (email,
>> bcc, cc). Is there a legitimate use case where you would want to send
>> an email to someone and at the same time cc/bcc the same address (or
>> cc and bcc)?
> No there isn't. Sounds like a case of fat fingers by someone at sometime
> in the past. I'll poke through the customer list and find it. Be right
> Just as an aside, the setup.pl script doesn't flag up any of these as an
> error, I think we need to get that fixed as all of the things that have
> bitten me so far are things that can easily exist in valid customer
> data. Just as a reminder:
> 1. Accounts without an associated header
> 2. Use of an invalid country name as default country
> 3. Duplicate email addresses
> All of these could be fixed with pre-qualification code like that that
> spots duplicate invoices, and customer and vendor numbers. But at the
> very least we need the script to say "Sorry guys, your data couldn't be
> migrated, for <this> reason".
Yep. As failures are found the pre-validation tests need to be add,
where we missed something.
However, if it is OK with you I would like to get you migrated first
and then figure out what checks need to be added.
As for the default country I am not 100% sure how we want to check
that yet. We may want to handle that differently.