[Vtigercrm-developers] unable to add user (a migration report)

[Prasad]

Alan,

Did you use the latest patches to migration 5.4.0 to 6.1.0?
Earlier patch from 5.4.0 to 6.0.0 - was losing the post-migration version
update so was leading to duplicate migration.

If you are on 6.0.0 and had migrated from 5.4.0 then checking the version
in vtiger_version table is important.

DB reporting 5.4.0 - even when it is in 6.1.0


Please let us know the migration from which it was migrated now.

   - Fresh from 5.4.0 to 6.1.0
   - Earlier from 5.4.0 to 6.0.0 and now from 6.0.0 to 6.1.0

Regards,
Prasad

*Connect with us on: *Twitter <http://twitter.com/vtigercrm> *I* Facebook
<http://www.facebook.com/pages/vtiger/226866697333578?sk=wall> *I* Blog
<https://blogs.vtiger.com/>* I* Wiki
<http://wiki.vtiger.com/vtiger6/index.php/Main_Page> *I* Website
<https://www.vtiger.com/>

On Mon, Oct 20, 2014 at 12:59 PM, Alan Lord <alanslists at gmail.com> wrote:

> On 19/10/14 11:21, Zebra Hosting wrote:
>
>> With several systems that have been migrated from 6.0 to 6.1 (sometimes
>> with already some beta code updates) I have issues where the admin is
>> unable to add new users.
>> I have added the latest SVN on top but that did not made a difference.
>>
>> Anyone an idea where this issue could come from and how/where to solve?
>>
>
> I did a fairly big migration (> 0.5million rows) this weekend from 5.4.0
> to 6.1.0. We'd done a few test migrations before to check it all worked.
>
> This weekend the migration from 5.4.0 to 6.0.0 seemed to run OK, but, as
> always, I did some checks before moving on...
>
> Although no errors were reported to the browser, the display just showed
> what it had done so far, reported it was all good, and gave me the button
> to go to the next step. However it turned out that the migration process
> that runs modules/Migration/schema/540_600RC.php had simply stopped
> around line 1574 just before the line:
>
>  Migration_Index_View::ExecuteQuery('UPDATE vtiger_currencies SET
>> currency_name = ? and currency_code = ?',
>>
>                 array('Hong Kong, Dollars', 'LvHong Kong, Dollars',
> 'HKD'));
>
> (php.ini was set for max_execution_time = 6000; (10 hours! - the script
> only takes about 20 minutes if that.)
>
> So I then copied the remaining code from that file (another 1000 lines or
> so that hadn't been run!) into a temporary one and modified it a little so
> I could run it from the command line - it ran to completion without error
> so I have no idea why it stopped halfway.
>
> Anyway - once this had completed, I then moved on to the 2nd part,
> migrating from 6.0.0 to 6.1.0. The first problem was that the first
> migration hadn't updated the entries in the vtiger_version table which, I
> think, triggered the 600 to 6.1.0 migration to re-run the 540_600 script!!!
> This caused a few minor issues with creation of duplicate blocks for some
> *calendar settings* fields but was fixable once I realised what had
> happened.
>
> The 600 to 610 script seemed to run correctly but the database still
> reported:
>
> old_version 5.4.0,
> current_version 5.4.0
>
> even though it is now 6.1.0.
>
> The user screen area gets totally locked-out if the calendar settings
> fields (now some default options for each user) are not set up correctly.
>
> Perhaps this would be an area for you to look at?
>
> vtiger devs: the migration scripts do not seem to be very robust and still
> need a bit more attention I think.
>
> Cheers
>
> Al
>
>
>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20141020/27303deb/attachment.html>