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
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 crmNotice : 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 crmNotice : 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:
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.
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.
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?
Windows-related issues are notoriously difficult for the core team to work on, the company culture is definitely Linux
If you can investigate a bit more, you might be able to help yourself and diagnose this a bit further…
That value is completely crazy for the function to return. If you can try to understand why the function is returning that, and what are the exact permissions on the file (icacls DOS command might help), it would be great. This could be a PHP bug… 
I am actually thinking if there would be a way for me to run the whole thing on linux (although the server is a windows)…
For development, I run a Windows Subsystem for Linux (v1) on my Windows 10 laptop, so I can run SuiteCRM on Ubuntu without leaving my preferred windows desktop.
Yeah but this is not a development CRM I have like 15 users and they do everyday work in it Thats also a reason why I am responding pretty slowly here. I always have to work on it at night 
Btw - thank you @pgr for all your advice.
I use it for development, but I don’t mean that it can’t be used for production. It seems to operate just fine. Although I would need to check if WSL hurts performance or not, I am not sure.
You can make SuiteCRM run on Windows in 3 ways:
I’ve done all 3 of those successfully. If I was going to install this for a production server, I would always use a virtualization layer, so I would go with 3.
See
Soooo, I was finally able to do an update (it only took me a few months although I only worked on it a few times during that time) and here is the sumup for anyone who needs it:
Fatal error: Uncaught Error: Cannot use object of type SplFileInfo as array in F:\xampp\htdocs\crm\include\utils\file_utils.php:57
Yeah it was that simple 
Yeah I am convinced of this also. It happens on Windows only.
But I can’t see a bug in our code here. I think it’s a PHP bug that only appears on Windows, but I would like to be sure…
If you edit the modules/users/vardefs.php file and remove the (30) in the index it will resolve the issue:
array(
'name' => 'idx_user_name',
'type' => 'index',
'fields' => array(
'user_name',
'is_group',
'status',
'last_name (30)',
'first_name (30)',
'id'
)
),
should be:
array(
'name' => 'idx_user_name',
'type' => 'index',
'fields' => array(
'user_name',
'is_group',
'status',
'last_name',
'first_name',
'id'
)
),