В последнее время все больше встречаются сообщения от пользователей, что при авторизации в админцентр появляется ошибка базы данных типа:
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Date: Sat, 22 Dec 2018 17:48:58 +0000 Error: 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'rows FROM ibf_sessions WHERE running_time > 1545500038' at line 1 IP Address: 127.0.0.2 - /admin/index.php?adsess=1ac9b00251fd8385aefbcf07a3e1f12d ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- mySQL query error: SELECT count(*) as rows FROM ibf_sessions WHERE running_time > 1545500038 .--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------. | File | Function | Line No. | |----------------------------------------------------------------------------+-------------------------------------------------------------------------------+-------------------| | adminsourcesbaseipsController.php | [admin_core_mycp_dashboard].doExecute | 306 | '----------------------------------------------------------------------------+-------------------------------------------------------------------------------+-------------------'
Связанно она с тем, что начиная с версии 10.2 в MariaDB слово rows является зарезервированным, и парсер воспринимает запрос с синтаксической ошибкой.
Исправляется очень просто — обрамлением ключевого слово rows в обратные кавычки, без необходимости замены на другое слово и правкой его в других участках кода.
Открыть /admin/applications/core/modules_admin/mycp/dashboard.php
Найти:
count(*) as rows
Заменить на
count(*) as `rows`
[quote name=’bfarber’ date=’10 June 2009 — 01:04 PM’ timestamp=’1244657079′ post=’1808846′]
Since you obviously know PHP, tell me — if you wanted error #4 in a file (where you obviously have no idea how many errors there are), how would you fseek to the appropriate spot? You fseek a byte position from the beginning of the file. You could use something arbitrary, like you said, and hope you hit a correct location — but as some errors can be long, and some can be short, that’s a stab in the dark and quite unreliable….
You could read 4KB from the beginning of the file, see if you have a delimiter, get next 4KB, repeat, until you hit the right spot. This could prevent you from having to load the entire file, I suppose.
No, I’d probably just load the entire file into memory and be done with it. I’d also probably add in a link to simply download the file (because you can use flush the buffer while outputting a file you don’t run into the same memory limit issues if done properly. That way you’d at least be able to download the file from the ACP without having to launch FTP, if you couldn’t actually view it there.
And to be fair, 20MB error logs are pretty rare. Most SQL error logs are 5MB or less.
What I was proposing was just a simple means to go back and forth through errors, not seek to a specific error. You’d start at the beginning, and allow the user to jump forward or backwards one error at a time, and jump to the beginning and end of the file. Logically it’s more work managing a buffer (or buffers) and scanning for the appropriate text and parsing it, but it’s not unreasonable. In this fashion you would not need to worry about the problems associated with loading a potentially enormous file (although I guess you could put a cap on the size of the file it would attempt to load). I agree that arbitrarily searching for a given error in the file (jump to error #4) is more demanding as you’d be slowly scanning through the file, and that loading the entire file if memory allows would be ideal.
Looking at the logs on my live forum, there are only a few and they are quite small (the largest is only 25K). Although if something goes wrong and you’re getting tons of driver errors, you’re probably going to be dealing with files significantly larger.
I’d be happy to see the entire file loaded into memory if that would work in most cases. I also like your suggestion of providing a list of the error files with a link to download each. Even that would save some time and make things easier.
..Al
20131112
ips driver error
полетела таблица ibf_posts.
запущено восстановление.
11 комментариев:
-
Unknown
комментирует… -
Ну, вот, даже IPBoard сам намекает, что его пора сменить.
-
12 ноября 2013 г. в 15:16:00 GMT+4
-
Unknown
комментирует… -
ну, вот, опять ipsdriver error.
-
15 ноября 2013 г. в 11:01:00 GMT+4
-
Unknown
комментирует… -
> ну, вот, опять ipsdriver error
опять полетела таблица ibf_posts.
запустил восстановление. -
15 ноября 2013 г. в 11:22:00 GMT+4
-
Unknown
комментирует… -
«шо, опять?» ©
или сейчас другая причина? недоступен, isup.me подтверждает, что не только у меня. -
16 ноября 2013 г. в 12:15:00 GMT+4
-
Unknown
комментирует… -
всё же опять ips driver error. а с чем вообще эта ошибка связана? логическая ошибка в таблицах или повреждение на уровне субд?
-
16 ноября 2013 г. в 12:58:00 GMT+4
-
Unknown
комментирует… -
> а с чем вообще эта ошибка связана?
повреждение таблиц.
чем оно вызывается — не знаю.
возможно — недостатком ресурсов. -
16 ноября 2013 г. в 15:30:00 GMT+4
-
Unknown
комментирует… -
написал письмо Виталию Липатову (директору etersoft-а) с просьбой, если это необходимо, увеличить лимиты ресурсов.
-
16 ноября 2013 г. в 16:08:00 GMT+4
-
Unknown
комментирует… -
unixforum.org недоступен, isup.me подтверждает, что не только у меня. новая проблема?
-
10 декабря 2013 г. в 14:56:00 GMT+4
-
Unknown
комментирует… -
хм, вроде бы заработало, но существенная задержка появилась. странно
-
10 декабря 2013 г. в 15:16:00 GMT+4
-
Unknown
комментирует… -
главная, подфорумы, список новых сообщений — открываются. но при попытке открыть тему получаю ips driver error
-
22 марта 2014 г. в 09:39:00 GMT+4
-
Unknown
комментирует… -
вроде заработало, пару раз ещё ошибку получил, больше не видно
спасибо
-
22 марта 2014 г. в 10:40:00 GMT+4
Отправить комментарий