Yes, sorry I didn't mention that, the SQL script to remove the duplicate ids
ran successfully, but 0 rows were affected.
Now I found out: To avoid or pass the liquibase checksum problems, there is
the possibility to run the following sql statement:
/update databasechangelog set md5sum=null/
After that I got even more database update exceptions. Most of them I could
solve by manually update the database.
Now I'm stuck again: The database migration manager, wants to create foreign
keys, but can't, because they already exist. Also by deleting the existing
foreign keys manually, there still is logged that the key is already used,
which in fact is right, because it's created by the migration manager. It
seems like some parts of the migration script runs twice.
/2016-07-26 12:59:47,331 ERROR [
]
c.x.x.s.m.liquibase [XWikiLiquibaseLogger.java:103] Change Set
liquibase.xml::R40000-030::sdumitriu failed. Error: Error executing SQL
ALTER TABLE [dbo].[xwikifloats] ADD CONSTRAINT [FKFB291FBF1DFF14A1] FOREIGN
KEY ([XWF_ID], [XWF_NAME]) REFERENCES [dbo].[xwikiproperties] ([XWP_ID],
[XWP_NAME]) ON UPDATE CASCADE: There is already an object named
'FKFB291FBF1DFF14A1' in the database.
liquibase.exception.DatabaseException: Error executing SQL ALTER TABLE
[dbo].[xwikifloats] ADD CONSTRAINT [FKFB291FBF1DFF14A1] FOREIGN KEY
([XWF_ID], [XWF_NAME]) REFERENCES [dbo].[xwikiproperties] ([XWP_ID],
[XWP_NAME]) ON UPDATE CASCADE: There is already an object named
'FKFB291FBF1DFF14A1' in the database./
Maybe it makes no sense to continue at this point? Thanks for you help so
far!
Clemens Klein-Robbenhaar wrote
The next thing that comes to my mind is to rerun the
SQL statements needed
to purge duplicate ids in the starts,
as in
http://jira.xwiki.org/browse/XWIKI-8129
I remember I posted this already in the thread, but I cannot see from the
thread if you ran them successfully.
As far as I understood they did not run without error so far?
If you did run them already, then this must be something else ...
It looks like the manual changes to the database confused the DB
upgraders; that is what the checksum error probably means.
Unfortunately I cannot find the place where the "checksums" are stored; I
guess the checksum must be updated manually, or some steps skipped
manually.
Clemens
----- Ursprüngliche Nachricht -----
Von: Jhaimerl
Am: Monday, 25.07.2016, 10:57
An: XWiki Users
Betreff: Re: [xwiki-users] Can't Upgrade from XWiki 3.5.1
> Hi Clemens,
>
> tried your advice and checked the installation folder for duplicate
> jar-files. Couldn't find any. I also used jwhich.jar for that purpose
> without any results. Also I repeated the whole process with different
> versions of XWiki (4.0, 4.2).
>
> Still I'm faced by the checksum errors you already mentioned around line
> 310.
>
> Any ideas or hints whatelse I could try?
>
> Many thanks and best regards
> Josef
>
>
> Clemens Klein-Robbenhaar wrote
>> Hi Josef,
>>
>> there are a lot of messages saying that one component wants to
>> overwrite
>> another component with the same name, class and priority.
>>
>> This usually happens if two XWiki version are unpacked on top of each
>> other, so the WEB-INF/lib contains the *.jar for both versions.
>> This might cause a lot of other problems, too
>>
>> Can you please check if you have some "duplicate" jars in your
>> WEB-INF/lib
>> directory e.g. both a xwiki-platform-component-script-4.2.jar and a
>> xwiki-platform-component-script-7.4.jar or the like?
>>
>> The actual problem then is around line 310 (next DB upgrade issue) - if
>> there are duplicate jars, hopefully this can be sorted out by repairing
>> the installation.
>> Otherwise we have to think about it again what might fix the issue this
>> time.
>>
>> hope this helps
>> Clemens
>>
>>
>> Jhaimerl wrote on Monday, 04.07.2016, 16:16
>>> Hi Clemens,
>>>
>>> first of thanks again. I followed your advice and executed the longish
>>> sql
>>> statement - didn't work.
>>> I then removed the relationships between tables and changed the
>>> datatype
>>> of
>>> the id columns to BIGINT manually by following the exceptions in the
>>> log.
>>>
>>> So I finally got through that part of the migration. Now I'm stuck with
>>> a
>>> new type of error, please see line 162 here
>>>
http://pastebin.com/YLzwvxmh.
>>>
>>> Has somebody ever seen this?
>>>
>>> Thank you and best regards
>>> Josef
>>>
>>>
>>> Clemens Klein-Robbenhaar wrote
>>>> Oh, this looks odd.
>>>>
>>>> The upgrade process first tried to find the name for the primary key;
>>>> that
>>>> is the statement:
>>>>
>>>> select @pkname=i.name from sysindexes i join sysobjects o ON i.id =
>>>> o.id
>>>> join sysobjects pk ON i.name = pk.name AND pk.parent_obj = i.id AND
>>>> pk.xtype = 'PK' join sysindexkeys ik on i.id = ik.id AND i.indid
=
>>>> ik.indid join syscolumns c ON ik.id = c.id AND ik.colid = c.colid
>>>> where
>>>> o.name = 'xwikidates'
>>>>
>>>> it then gets a result "PK__xwikidates__6FD49106"
>>>>
>>>> but when it tries to drop this constrain via:
>>>>
>>>> 'alter table [dbo].[xwikidates] drop constraint ' + @pkname
>>>>
>>>> it fails with 'PK__xwikidates__6FD49106' is not a constraint.
Huh?
>>>>
>>>> Can you try to run that longish SQL Query from an SQL-console or the
>>>> like,
>>>> just to see if that returns the same result?
>>>>
>>>> To proceed the update, maybe it helps to drop the constraint for the
>>>> primary key of the 'xwikidates' table manually and see what the
next
>>>> error
>>>> is, probably there are more PK-constraints with that problem.
>>>> (I hope you have backups, otherwise this is very bad advice ;) )
>>>>
>>>> Clemens
>>>>
>>>>> First of all thank you for your answer, Clemens.
>>>>>
>>>>> There a different exceptions in the log-file for executing
>>>>> sql-statements.
>>>>> Please see
http://pastebin.com/BFABwpNz.
>>>>>
>>>>> All the errors are in relation to the xwikidates table.
>>>>> Do you have any idea how to fix this?
>>>>>
>>>>> Thanks again and best regards
>>>>> Josef
>>>>>
>>>>>
>>>>> Clemens Klein-Robbenhaar wrote
>>>>>> It seems a DB migration failed; you can find the error in the
log
>>>>>> file
>>>>>> after startup, above of the messages you posted.
>>>>>>
>>>>>> It is likely that it is the statistics migration
>>>>>>
>>>>>> You can try the SQL statements from here:
>>>>>>
http://jira.xwiki.org/browse/XWIKI-8129
>>>>>>
>>>>>> as found in the release notes of 4.3:
>>>>>>
>>>>>>
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki43#HGener…
>>>>>>
>>>>>> If it is not the statistics, please locate the error from the
failed
>>>>>> migration
>>>>>> (should be somewhere after the line: "Checking Hibernate
mapping and
>>>>>> updating schema if needed for wiki [xwiki]" )
>>>>>>
>>>>>> HTH
>>>>>> Clemens
>>>>>>
>>>>>>
>>>>>> ----- Ursprüngliche Nachricht -----
>>>>>> Von: Jhaimerl
>>>>>> Am: Tuesday, 28.06.2016, 09:59
>>>>>> An: Xwiki Users
>>>>>> Betreff: [xwiki-users] Can't Upgrade from XWiki 3.5.1
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm trying to upgrade an existing XWiki Instance
(V3.5.1). It's
>>>>>>> running
>>>>>>> with
>>>>>>> a MSSQL database.
>>>>>>>
>>>>>>> I already tried the following (see referenced links below)
and
>>>>>>> upgrades
>>>>>>> to
>>>>>>> different higher versions of XWiki e.g. 4.x, 5.4.x. However
I
>>>>>>> always
>>>>>>> get
>>>>>>> this exception
http://pastebin.com/yeaFQAtt.
>>>>>>>
>>>>>>>
http://xwiki.475771.n2.nabble.com/Another-migration-problem-3-5-to-4-1-3-td…
>>>>>>>
http://lists.xwiki.org/pipermail/users/2012-August/023537.html
>>>>>>>
http://xwiki.475771.n2.nabble.com/Failed-migration-from-3-0-to-4-3-1-td7583…
>>>>>>>
>>>>>>> Does somebody have any hints how to solve this?
>>>>>>>
>>>>>>> Many thanks in advance!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>
>> _______________________________________________
>> users mailing list
>
>
users@
>
>
>
>
>
>
>
> --
> View this message in context:
>
http://xwiki.475771.n2.nabble.com/Can-t-Upgrade-from-XWiki-3-5-1-tp7600118p…
> Sent from the XWiki- Users mailing list archive at
Nabble.com.
> _______________________________________________
> users mailing list
>
_______________________________________________
users mailing list