Large Scale Planes Posted January 18, 2021 Posted January 18, 2021 (edited) 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, 2021 by Large Scale Planes
Daniel F Posted January 18, 2021 Posted January 18, 2021 1 minute ago, Large Scale Planes said: 'm guessing I'll have to log a ticket for this one yes please:)
CoffeeCake Posted January 18, 2021 Posted January 18, 2021 You likely need to repair your database and should consider converting to InnoDB.
Large Scale Planes Posted January 18, 2021 Author Posted January 18, 2021 2 minutes ago, Daniel F said: yes please:) Doing it now! Kev 1 minute ago, 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
CoffeeCake Posted January 18, 2021 Posted January 18, 2021 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.
Large Scale Planes Posted January 18, 2021 Author Posted January 18, 2021 12 minutes ago, 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
CoffeeCake Posted January 18, 2021 Posted January 18, 2021 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.
Large Scale Planes Posted January 18, 2021 Author Posted January 18, 2021 37 minutes ago, 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
Recommended Posts