Forums - Thread Details
  • State Not Answered
  • Replies 6 replies
  • Subscribers 320 subscribers
  • Views 1457 views
  • Users 0 members are here
Forum Actions
Related

default_dashboard unknown column

Kunal singh

hi All,

We have just upgraded our instance from 7.9.5 to 8.0.2 , upgrade failed at post_upgrade checks

we are witnessing following error on all module pages - Unknown column 'dashboards.default_dashboard'

HTTP: 500 Internal Server Error

An exception occurred while executing 'SELECT dashboards.id, dashboards.date_modified dashboards__date_modified FROM dashboards LEFT JOIN sugarfavorites sf_dashboards ON (sf_dashboards.module = ?) AND (sf_dashboards.record_id = dashboards.id) AND (sf_dashboards.assigned_user_id = ?) AND (sf_dashboards.deleted = ?) WHERE ((dashboards.dashboard_module = ?) AND ((sf_dashboards.id IS NOT NULL) OR (dashboards.default_dashboard = ?)) AND (dashboards.view_name = ?)) AND (dashboards.deleted = ?) ORDER BY dashboards.date_modified DESC, dashboards.id DESC LIMIT 18446744073709551615 OFFSET 0' with params ["Dashboards", "1", 0, "pmse_Business_Rules", 1, "records", 0]: Unknown column 'dashboards.default_dashboard' in 'where clause'

could someone provide me with dashboards table create query please post 8.0.2 upgrade.

Parents
  • 0

    BTW did you try a QRR to see if there were any pending SQL queries that needed to be executed?

  • 0 in reply to Francesca Shiekh

    One more thing, set your log level to debug. 

    I was looking at my notes and I had a similar issue from 7.9.x to 8.0

    In my case it was an error in one of my custom files that prevented the upgrade from completing.

    When you put your log level to debug and continue the upgrade you should get a better indication of where - or at least in what module - the error is happening that is preventing your upgrade from completing.

    See if that helps.

    This was the suggestion that support sent me:

    After lowering your logger level to debug and rerunning the upgrader, your sugarcrm.log should have an entry that prints something similar to this:

    UpgradeSidecarGridLayoutMetaDataParser->__construct( recordview , <MODULENAME> , )

    The modulename in this case will be key. From there you should be able to go into either of these two paths and verify the structure of the view defs that might be there:

    /custom/<MODULENAME>/clients/base/views/record/record.php (This might not exist)

    /<MODULENAME>/clients/base/views/record/record.php

    If the custom view file exists, start with this one. Otherwise look in your OOTB view file. What you are looking for is a PHP array that has an initial structure of:

    $viewdefs['<MODULENAME>']['base']['view']['record'] = array(

    If the structure is anything other than that you will encounter the errors you are seeing on the upgrader.

    I hope this helps to identify the issue you were seeing where the upgrader was dying before completion. Please note that while it might appear that your instance is functional after upgrade when the upgrader has stopped midway it actually is in a broken state.

    As it relates to this issue, to “fix” this issue, you will need to identify the suspect files on your pre-upgrade instance and remove them from your system. You can do this by renaming the file from record.php to something like record.php.old, or simply deleting the file altogether. After doing this, and rerunning the upgrader, you should be able to complete the process.

Reply
  • 0 in reply to Francesca Shiekh

    One more thing, set your log level to debug. 

    I was looking at my notes and I had a similar issue from 7.9.x to 8.0

    In my case it was an error in one of my custom files that prevented the upgrade from completing.

    When you put your log level to debug and continue the upgrade you should get a better indication of where - or at least in what module - the error is happening that is preventing your upgrade from completing.

    See if that helps.

    This was the suggestion that support sent me:

    After lowering your logger level to debug and rerunning the upgrader, your sugarcrm.log should have an entry that prints something similar to this:

    UpgradeSidecarGridLayoutMetaDataParser->__construct( recordview , <MODULENAME> , )

    The modulename in this case will be key. From there you should be able to go into either of these two paths and verify the structure of the view defs that might be there:

    /custom/<MODULENAME>/clients/base/views/record/record.php (This might not exist)

    /<MODULENAME>/clients/base/views/record/record.php

    If the custom view file exists, start with this one. Otherwise look in your OOTB view file. What you are looking for is a PHP array that has an initial structure of:

    $viewdefs['<MODULENAME>']['base']['view']['record'] = array(

    If the structure is anything other than that you will encounter the errors you are seeing on the upgrader.

    I hope this helps to identify the issue you were seeing where the upgrader was dying before completion. Please note that while it might appear that your instance is functional after upgrade when the upgrader has stopped midway it actually is in a broken state.

    As it relates to this issue, to “fix” this issue, you will need to identify the suspect files on your pre-upgrade instance and remove them from your system. You can do this by renaming the file from record.php to something like record.php.old, or simply deleting the file altogether. After doing this, and rerunning the upgrader, you should be able to complete the process.

Children
No Data