Suddenly our community site is giving the old EX145 error code when trying to log in, or when logged in and trying to load a new page. This usually indicates that the table ibf_core_sessions has crashed, but in this case, repairing the table shows no errors and has no effect on the problem. So, I'm completely stuck! For what it's worth, the forums continue to function normally if you're logged out, but any attempt to log in generates the error, including for the ACP.

I'm guessing I'll have to log a ticket for this one, but thought I might try the brains trust first.

Kevin

Edited January 18, 20214 yr by Large Scale Planes

  On 1/18/2021 at 8:15 AM, Large Scale Planes said:

'm guessing I'll have to log a ticket for this one

yes please:)

You likely need to repair your database and should consider converting to InnoDB.

  On 1/18/2021 at 8:17 AM, Daniel F said:

yes please:)

Doing it now!

Kev

  On 1/18/2021 at 8:18 AM, Paul E. said:

You likely need to repair your database and should consider converting to InnoDB.

Well, ibf_core_sessions definitely isn't crashed, and I have no idea what other table/s could be the culprit. Repairing all 200 doesn't really seem feasible to me. And surely Invision would set the tables up as required for its own product, so if they're MyISAM, then surely they're meant to be?

Kevin

Well, in earlier versions of IPB, they were likely MyISAM. In a new install today, they're all InnoDB. I'm assuming you're running 4.5.

If so, you should move to InnoDB to prevent corruption issues.

  On 1/18/2021 at 8:28 AM, Paul E. said:

Well, in earlier versions of IPB, they were likely MyISAM. In a new install today, they're all InnoDB. I'm assuming you're running 4.5.

If so, you should move to InnoDB to prevent corruption issues.

Right, makes sense. I've never done that conversion, and was under the impression that it can result in data loss, but I guess I'll have to investigate further.

Kev

As it happens, I went ahead and ran a repair on all tables anyway, and this seems to have fixed the issue (pending further testing). I'd love to know what table/s were involved, but sadly, phpMyAdmin timed out while running the repairs.

Kev

You should not use phpMyAdmin for operations like this as a best practice. Instead, use an SSH connection and perform the operations directly on your server.

  On 1/18/2021 at 8:46 AM, Paul E. said:

You should not use phpMyAdmin for operations like this as a best practice. Instead, use an SSH connection and perform the operations directly on your server.

I usually use Sequel Pro for remote connections and management, but it seemed easier to run a repair all style command from phpMyAdmin, rather than repair each table individually with SP.

Kev