Problem solved after upgrading to postgres to 8.4 and re-ran the indexer!
Cheers,
Osama Alkadi
On 03/11/2010, at 1:57 PM, Steve Swinsburg wrote:
Thanks Stuart, that did the trick. We are now working through the invalid
records.
For reference though, we had to enable debugging on the
Hi,
We've created a new dump with -E UNICODE added to the dump command, imported it
into a clean UTF-8 database, upgraded via the 15-16 sql update script which
completes successfully, but as soon as we run the index-init script again, the
same issue occurs. It would be helpful if the exception
Steve - I used Google and found this:
http://archives.postgresql.org/pgsql-bugs/2005-11/msg00269.php
When I run the 'locale' command here, I get this:
LC_CTYPE=en_US.UTF-8
The same thing when I check from psql:
gkrtrain= show lc_ctype
gkrtrain- ;
lc_ctype
-
en_US.UTF-8
(1
Hi Steve,
As well as Keith's suggestion of inspecting your locale, I'd try a redump of
the database with -E UNICODE passed to 'pg_dump', otherwise the dumped
tables will still be in their original encoding.
http://www.postgresql.org/docs/8.4/static/app-pgdump.html
Cheers,
Kim
On 28 October
Hi all,
We've completed another restore but are still having the same issue. This time
we created a new database with the UNICODE encoding as per the installation
manual:
createdb -U dspace -E UNICODE dspace
We then took an export of the current production database:
pg_dump dspace
Hi all,
We are having a problem upgrading an instance of dspace from 1.5.x-1.6.2. We
built the new 1.6.2 code and took a snapshot of our old production database and
migrated in back to our dev environment (along with the assets). We then ran
the db upgrade script.
Now, when running the
Hi Steve,
Just to check, has your new/dev database been created with UTF8 character
encoding? (pass -E UNICODE or -E UTF8 to createdb)
Cheers,
Kim
On 25 October 2010 14:57, Steve Swinsburg steve.swinsb...@gmail.com wrote:
Hi all,
We are having a problem upgrading an instance of dspace from
Hi Kim,
We took a *copy* of the database and refreshed it back to dev, so it is
identical to the production one, then upgraded it in dev. So I'll need to find
out if the original database from production was created that way.
Perhaps we should take a dump of the production database instead,
8 matches
Mail list logo
