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 index-i
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 wrote:
> Hi all,
>
> We are having a problem upgrading an instance of dspace from 1.5.x-1.6.2.
> We buil
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, and
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 > dspace-prod.
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 201
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
Hi Steve,
See:
-
https://wiki.duraspace.org/display/DSPACE/TechnicalFaq#TechnicalFaq-SettingloggingleveluptoDEBUG
If you set your logging to DEBUG, they will be *very* verbose, but should show
you the item that is failing, and the SQL queries in particular that are
causing the problem.
Than
Thanks Stuart, that did the trick. We are now working through the invalid
records.
For reference though, we had to enable debugging on the dspace packages as well:
log4j.logger.org.dspace=DEBUG, A1
cheers,
Steve
On 01/11/2010, at 4:27 PM, Stuart Lewis wrote:
> Hi Steve,
>
> See:
>
> -
> ht
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 d
10 matches
Mail list logo
