Upgrade Wizard Error on 7.10.25

Hello Community,

I am trying to upgrade our SuiteCRM with the Upgrade Wizard but getting the following error
Version:1.0 StartHTML:000000190 EndHTML:000006183 StartFragment:000004863 EndFragment:000006133 StartSelection:000004863 EndSelection:000006133 SourceURL:https://localhost/index.php KASTOcrm

Notice : Undefined index: additional_step in C:\Apache24\htdocs\modules\UpgradeWizard\index.php on line 291

Fatal error : Uncaught Error: Cannot use object of type SplFileInfo as array in C:\Apache24\htdocs\include\utils\file_utils.php:57 Stack trace: #0 C:\Apache24\htdocs\modules\UpgradeWizard\uw_utils.php(4579): clean_path() #1 C:\Apache24\htdocs\modules\UpgradeWizard\systemCheck.php(83): dirInArray() #2 C:\Apache24\htdocs\modules\UpgradeWizard\index.php(292): require(‘C:\Apache24\htd…’) #3 C:\Apache24\htdocs\include\MVC\View\SugarView.php(818): include_once(‘C:\Apache24\htd…’) #4 C:\Apache24\htdocs\include\MVC\View\views\view.classic.php(72): SugarView->includeClassicFile() #5 C:\Apache24\htdocs\include\MVC\View\SugarView.php(211): ViewClassic->display() #6 C:\Apache24\htdocs\include\MVC\Controller\SugarController.php(435): SugarView->process() #7 C:\Apache24\htdocs\include\MVC\Controller\SugarController.php(375): SugarController->processView() #8 C:\Apache24\htdocs\include\MVC\SugarApplication.php(113): SugarController->execute() #9 C:\Apache24\htdocs\index.php(52): SugarApplication->execute() #10 {main} thrown in C:\Apache24\htdocs\include\utils\file_utils.php on line 57

Installation is on
Windows Server 2019
Apache 2.4
PHP 7.4

Anyone can help with this ?

Best regards
Ben

Hi. sorry for this.

We have a half-baked fix. You would need to apply this change:

and then replace this function in uw_utils.php

–> https://github.com/mattlorimer/SuiteCRM/blob/fix/upgrade/modules/UpgradeWizard/uw_utils.php#L4577-L4588

with this code:

function dirInArray($dir, $dirsArray)
{
    $dir = clean_path($dir);
	$cwd = clean_path(getcwd());

    foreach ($dirsArray as $aDir) {
        // Match the substring only at the beginning of the path:
        if (strpos($dir, $cwd . '/' . $aDir) === 0) {
            return true;
        }
    }

    return false;
}

But still, I fear that you might still see the error, because the installer will actually start by replacing these files with the versions inside the packages, overriding the changes you made. To work around that, you’d have to edit the files inside the zip (unzip+change+zip again). That is a lot of work :frowning:

That is the part that I will need to investigate a bit more…

1 Like

I just tried the above and I think it will work. You might have the same problems in the next upgrade you try, but meanwhile we have some more time to get a better fix.

Hi pgr,

ok so far your fix was working. But when I got to step Commit I got this error on hitting next

Notice : Undefined index: additional_step in C:\Apache24\htdocs\modules\UpgradeWizard\index.php on line 291
Database failure. Please refer to suitecrm.log for details.

And here is the part from the suitecrm.log
#0 C:\Apache24\htdocs\include\database\DBManager.php(353): sugar_die()
#1 C:\Apache24\htdocs\include\database\DBManager.php(328): DBManager->registerError()
#2 C:\Apache24\htdocs\include\database\SqlsrvManager.php(235): DBManager->checkError()
#3 C:\Apache24\htdocs\include\database\DBManager.php(1170): SqlsrvManager->query()
#4 C:\Apache24\htdocs\include\database\DBManager.php(982): DBManager->addIndexes()
#5 C:\Apache24\htdocs\include\database\DBManager.php(764): DBManager->repairTableParams()
#6 C:\Apache24\htdocs\modules\UpgradeWizard\end.php(82): DBManager->repairTable()
#7 C:\Apache24\htdocs\modules\UpgradeWizard\index.php(292): require(‘C:\Apache24\htd…’)
#8 C:\Apache24\htdocs\include\MVC\View\SugarView.php(834): include_once(‘C:\Apache24\htd…’)
#9 C:\Apache24\htdocs\include\MVC\View\views\view.classic.php(72): SugarView->includeClassicFile()
#10 C:\Apache24\htdocs\include\MVC\View\SugarView.php(226): ViewClassic->display()
#11 C:\Apache24\htdocs\include\MVC\Controller\SugarController.php(435): SugarView->process()
#12 C:\Apache24\htdocs\include\MVC\Controller\SugarController.php(375): SugarController->processView()
#13 C:\Apache24\htdocs\include\MVC\SugarApplication.php(113): SugarController->execute()
#14 C:\Apache24\htdocs\index.php(52): SugarApplication->execute()
#15 {main}

That one is new to me, I don’t think it is related to any of the changes we made.

Anyway, the actual database error is a few lines before that part you pasted, it’s before #0

Please include that text so we can have a look. It seems to be having trouble creating some index…

Sorry I couldn’t work on the error yet.

Here is what you asked for

Sun Apr 12 21:54:54 2020 [3568][1][FATAL] Error adding index: Query Failed:CREATE INDEX idx_user_name ON users (user_name,is_group,status,last_name (30),first_name (30),id)::: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Incorrect syntax near ‘(’.
Sun Apr 12 21:54:54 2020 [3568][1][FATAL] Exception handling in C:\Apache24\htdocs\include\MVC\Controller\SugarController.php:400
Sun Apr 12 21:54:54 2020 [3568][1][FATAL] Exception in Controller: Database failure. Please refer to suitecrm.log for details.
Sun Apr 12 21:54:54 2020 [3568][1][FATAL] backtrace:
#0 C:\Apache24\htdocs\include\database\DBManager.php(353): sugar_die()
#1 C:\Apache24\htdocs\include\database\DBManager.php(328): DBManager->registerError()
#2 C:\Apache24\htdocs\include\database\SqlsrvManager.php(235): DBManager->checkError()
#3 C:\Apache24\htdocs\include\database\DBManager.php(1170): SqlsrvManager->query()
#4 C:\Apache24\htdocs\include\database\DBManager.php(982): DBManager->addIndexes()
#5 C:\Apache24\htdocs\include\database\DBManager.php(764): DBManager->repairTableParams()
#6 C:\Apache24\htdocs\modules\UpgradeWizard\end.php(82): DBManager->repairTable()
#7 C:\Apache24\htdocs\modules\UpgradeWizard\index.php(292): require(‘C:\Apache24\htd…’)
#8 C:\Apache24\htdocs\include\MVC\View\SugarView.php(834): include_once(‘C:\Apache24\htd…’)
#9 C:\Apache24\htdocs\include\MVC\View\views\view.classic.php(72): SugarView->includeClassicFile()
#10 C:\Apache24\htdocs\include\MVC\View\SugarView.php(226): ViewClassic->display()
#11 C:\Apache24\htdocs\include\MVC\Controller\SugarController.php(435): SugarView->process()
#12 C:\Apache24\htdocs\include\MVC\Controller\SugarController.php(375): SugarController->processView()
#13 C:\Apache24\htdocs\include\MVC\SugarApplication.php(113): SugarController->execute()
#14 C:\Apache24\htdocs\index.php(52): SugarApplication->execute()
#15 {main}

Have you gone into the Admin / Repairs / Quick Repair and Rebuild? Scroll down to the bottom and check if there is a button to sync database with vardefs. If there is, press it.

Yes there was that button. After pressing it I get a database error again

Mon Apr 13 10:21:37 2020 [3568][1][FATAL] Executing repair query: Query Failed:CREATE INDEX idx_user_name ON users (user_name,is_group,status,last_name (30),first_name (30),id)::: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Incorrect syntax near ‘(’.
Mon Apr 13 10:21:37 2020 [3568][1][FATAL] Exception handling in C:\Apache24\htdocs\include\MVC\Controller\SugarController.php:400
Mon Apr 13 10:21:37 2020 [3568][1][FATAL] Exception in Controller: Database failure. Please refer to suitecrm.log for details.
Mon Apr 13 10:21:37 2020 [3568][1][FATAL] backtrace:
#0 C:\Apache24\htdocs\include\database\DBManager.php(353): sugar_die()
#1 C:\Apache24\htdocs\include\database\DBManager.php(328): DBManager->registerError()
#2 C:\Apache24\htdocs\include\database\SqlsrvManager.php(235): DBManager->checkError()
#3 C:\Apache24\htdocs\modules\Administration\repairDatabase.php(95): SqlsrvManager->query()
#4 C:\Apache24\htdocs\include\MVC\View\SugarView.php(834): include_once(‘C:\Apache24\htd…’)
#5 C:\Apache24\htdocs\include\MVC\View\views\view.classic.php(72): SugarView->includeClassicFile()
#6 C:\Apache24\htdocs\include\MVC\View\SugarView.php(226): ViewClassic->display()
#7 C:\Apache24\htdocs\include\MVC\Controller\SugarController.php(435): SugarView->process()
#8 C:\Apache24\htdocs\include\MVC\Controller\SugarController.php(375): SugarController->processView()
#9 C:\Apache24\htdocs\include\MVC\SugarApplication.php(113): SugarController->execute()
#10 C:\Apache24\htdocs\index.php(52): SugarApplication->execute()
#11 {main}

Should I try to execute the script on the MSSQL server itself ?

Yes, you can try.

You can also search online for other people who had this issue. This came from a change of the field sizes from 30 to 100, which had some problem, I can’t remember what, and so it was a complicated upgrade for many people. Then I believe there was a second change on our code to make it consistent again. I was convinced everything was solved now, maybe some minor detail is making things go wrong in your case.

Ok. With removing the two (30) from the script it run and I got

Database tables are synced with vardefs

Then I did try the Repair Button once more and it still says there are differences and offers me a second script to execute

/* Table : users /
/COLUMNS/
/
INDEXES */

/*INDEX MISMATCH WITH DATABASE - idx_user_name - ROW idx_user_name index [0] => ‘user_name’ [1] => ‘is_group’ [2] => ‘status’ [3] => ‘last_name’ [4] => ‘first_name’ [5] => ‘id’ /
/
VARDEF - idx_user_name - ROW idx_user_name index [0] => ‘user_name’ [1] => ‘is_group’ [2] => ‘status’ [3] => ‘last_name (30)’ [4] => ‘first_name (30)’ [5] => ‘id’ */
DROP INDEX idx_user_name ON users;;
CREATE INDEX idx_user_name ON users (user_name,is_group,status,last_name (30),first_name (30),id);;

/* Table : jjwg_maps */
/COLUMNS/
/*MISMATCH WITH DATABASE - distance - ROW [name] => ‘distance’ [type] => ‘real’ [len] => ‘4’ /
/
VARDEF - distance - ROW[required] => ‘’ [name] => ‘distance’ [vname] => ‘LBL_DISTANCE’ [type] => ‘float’ [massupdate] => ‘0’ [comments] => ‘’ [help] => ‘Distance’ [importable] => ‘true’ [duplicate_merge] => ‘disabled’ [duplicate_merge_dom_value] => ‘0’ [audited] => ‘1’ [reportable] => ‘1’ [len] => ‘9,4’ [size] => ‘20’ [precision] => ‘4’ [dbType] => ‘float’ [default] => ‘’ /
ALTER TABLE jjwg_maps ALTER COLUMN [distance] float(9) NULL ;
;
/
INDEXES /
/
Table : jjwg_markers */
/COLUMNS/
/*MISMATCH WITH DATABASE - jjwg_maps_lat - ROW [name] => ‘jjwg_maps_lat’ [type] => ‘real’ [len] => ‘4’ [default] => ‘0.00000000’ /
/
VARDEF - jjwg_maps_lat - ROW[required] => ‘’ [name] => ‘jjwg_maps_lat’ [vname] => ‘LBL_JJWG_MAPS_LAT’ [type] => ‘float’ [massupdate] => ‘0’ [default] => ‘0.00000000’ [comments] => ‘’ [help] => ‘Latitude’ [importable] => ‘true’ [duplicate_merge] => ‘disabled’ [duplicate_merge_dom_value] => ‘0’ [audited] => ‘’ [reportable] => ‘1’ [len] => ‘10,8’ [size] => ‘20’ [precision] => ‘8’ [dbType] => ‘float’ */
ALTER TABLE jjwg_markers DROP CONSTRAINT DF__jjwg_mark__jjwg___18D6A699 ALTER TABLE jjwg_markers ALTER COLUMN [jjwg_maps_lat] float(10) NULL ;
ALTER TABLE jjwg_markers ADD DEFAULT ‘0.00000000’ FOR jjwg_maps_lat ;
/*MISMATCH WITH DATABASE - jjwg_maps_lng - ROW [name] => ‘jjwg_maps_lng’ [type] => ‘real’ [len] => ‘4’ [default] => ‘0.00000000’ /
/
VARDEF - jjwg_maps_lng - ROW[required] => ‘’ [name] => ‘jjwg_maps_lng’ [vname] => ‘LBL_JJWG_MAPS_LNG’ [type] => ‘float’ [massupdate] => ‘0’ [default] => ‘0.00000000’ [comments] => ‘’ [help] => ‘Longitude’ [importable] => ‘true’ [duplicate_merge] => ‘disabled’ [duplicate_merge_dom_value] => ‘0’ [audited] => ‘’ [reportable] => ‘1’ [len] => ‘11,8’ [size] => ‘20’ [precision] => ‘8’ [dbType] => ‘float’ /
ALTER TABLE jjwg_markers DROP CONSTRAINT DF__jjwg_mark__jjwg___19CACAD2 ALTER TABLE jjwg_markers ALTER COLUMN [jjwg_maps_lng] float(11) NULL ;
ALTER TABLE jjwg_markers ADD DEFAULT ‘0.00000000’ FOR jjwg_maps_lng ;
/
INDEXES /
/
Table : jjwg_address_cache */
/COLUMNS/
/*MISMATCH WITH DATABASE - lat - ROW [name] => ‘lat’ [type] => ‘real’ [len] => ‘4’ /
/
VARDEF - lat - ROW[required] => ‘’ [name] => ‘lat’ [vname] => ‘LBL_LAT’ [type] => ‘float’ [massupdate] => ‘0’ [comments] => ‘’ [help] => ‘Latitude’ [importable] => ‘true’ [duplicate_merge] => ‘disabled’ [duplicate_merge_dom_value] => ‘0’ [audited] => ‘’ [reportable] => ‘1’ [len] => ‘10,8’ [size] => ‘20’ [precision] => ‘8’ [dbType] => ‘float’ [default] => ‘’ */
ALTER TABLE jjwg_address_cache ALTER COLUMN [lat] float(10) NULL ;
;
/*MISMATCH WITH DATABASE - lng - ROW [name] => ‘lng’ [type] => ‘real’ [len] => ‘4’ /
/
VARDEF - lng - ROW[required] => ‘’ [name] => ‘lng’ [vname] => ‘LBL_LNG’ [type] => ‘float’ [massupdate] => ‘0’ [comments] => ‘’ [help] => ‘Longitude’ [importable] => ‘true’ [duplicate_merge] => ‘disabled’ [duplicate_merge_dom_value] => ‘0’ [audited] => ‘’ [reportable] => ‘1’ [len] => ‘11,8’ [size] => ‘20’ [precision] => ‘8’ [dbType] => ‘float’ [default] => ‘’ /
ALTER TABLE jjwg_address_cache ALTER COLUMN [lng] float(11) NULL ;
;
/
INDEXES */

There I needed to remove the (30) again and got the same message that the tables are synced now. But every time I go back to repair it still says there are differences and wants to run the last script.
So did this work now or do I have something else to do ?

Additionally since the update I get a lot of php errors on different sites. Some of them were index errors that are gone since I did the repair.

But here are two examples for other errors. I don’t know how many are there as I need to check every single site.

User Management
Version:1.0 StartHTML:000000225 EndHTML:000006147 StartFragment:000005157 EndFragment:000006097 StartSelection:000005157 EndSelection:000006097 SourceURL:https://crm.local.com/index.php?module=Users&action=index crm

Notice : Trying to access array offset on value of type null in C:\Apache24\htdocs\include\SearchForm\SearchForm2.php on line 536

Notice : Trying to access array offset on value of type null in C:\Apache24\htdocs\include\SearchForm\SearchForm2.php on line 536

Notice : Trying to access array offset on value of type null in C:\Apache24\htdocs\include\SearchForm\SearchForm2.php on line 536

Notice : Trying to access array offset on value of type null in C:\Apache24\htdocs\include\SearchForm\SearchForm2.php on line 536

Notice : Trying to access array offset on value of type null in C:\Apache24\htdocs\include\SearchForm\SearchForm2.php on line 536

Notice : Trying to access array offset on value of type null in C:\Apache24\htdocs\include\SearchForm\SearchForm2.php on line 536

System Settings
Version:1.0 StartHTML:000000235 EndHTML:000005242 StartFragment:000005054 EndFragment:000005192 StartSelection:000005054 EndSelection:000005192 SourceURL:https://crm.local.com/index.php?module=Configurator&action=EditView crm

Notice : Undefined index: google_auth_json in C:\Apache24\htdocs\modules\Configurator\views\view.edit.php on line 171

The PHP notices you can safely ignore, make sure you have display_errors turned off in your php.ini, and then restart web server.

The discrepancy is between what is in the database, and the vardefs for some module, so you might want to check files like these:
modules/jjwg_Markers/vardefs.php
modules/Users/vardefs.php
etc

Also check if you have any vardefs files in custom/modules that might be overriding these; that would explain the confusion.

But I am uncertain of what things should look like in the definitive state.

@abuelodelanada can we get your help here, please?

I’m not OP, but I had a simillar problem and your advices helped me. Thank you.

I’m glad it was useful.

There are two newer, more complete PRs for upgrade issues here:

2 Likes

This topic is now outdated - the correct answer now is to go with the new versions - 7.10.27 and 7.11.15.

Keep your eye on the Release notes:

There’s a link there to an extra package that you should use in case you still run into upgrade errors.

1 Like

Hey @pgr - your solution doesnt work for me. I am on 7.11.13 and I can’t upgrade. When I try to upgrade I have this exact bug in preflight check (I am on windows):

Fatal error: Uncaught Error: Cannot use object of type SplFileInfo as array in F:\xampp\htdocs\crm\include\utils\file_utils.php:57

And if I use your suggested solution - which is to download upgrade patch and install it - then the upgrade patch messes up file permissions as it was already mentioned in those threads:

Or to be specific - upgrade patch is probably not written correctly for windows cause it doesnt do anything to file permissions but upgrade wizard then “thinks” that the permissions are wrong although it didnt change.

1 Like

I created a git for this - there is quite a lot of changes in systemCheck.php - there is probably bug somewhere here:

$filesNotWritable[$i] = $file->getPathname();
        $perms = substr(sprintf('%o', $file->getPerms()), -4);
        $owner = $file->getOwner();
        $group = $file->getGroup();
        if (!$isWindows && function_exists('posix_getpwuid')) {
            $ownerData = posix_getpwuid($owner);
            $owner = !empty($ownerData) ? $ownerData['name'] : $owner;
        }

Or maybe not of course… I think it gets incorrect permissions from root folder files.

Can you check what $file->getPerms() is returning in your system?

Yes it returns:

3320633206 for each file in root folder (the ones with so called bad permissions)

Should I start an issue on suitecrm github or something like that?