Database error - and no idea how to go about resolving this

[pepf]

dB things are something I don't dare messing with. Can anyone suggest how to resolve this, please? There is the following error message:
--------
Database Error: 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 'offset
FROM smf_log_spider_stats
WHERE stat_date < '2024-10-01'' at line 1


SELECT COUNT(*) AS offset
FROM smf_log_spider_stats
WHERE stat_date < '2024-10-01
------


Thanks in advance
Peter

[Bugo]

Open ManageSearchEngines.php, find

Code Select Expand

SELECT COUNT(*) AS offsetand replace with

Code Select Expand

SELECT COUNT(*)

[Kindred]

Smf version?

Mariadb version?

[Arantor]

Definite candidate for 2.1.5.

[pepf]

2.1.5?
Is that coming out any time soon?

SMF 2.14  /   10.6.20-MariaDB-cll-lve

I'm afraid I can't find a file with the name ManageSearchEngines.php

Thanks.

[Arantor]

2.1.5?
Is that coming out any time soon?

SMF 2.14  /   10.6.20-MariaDB-cll-lve

I'm afraid I can't find a file with the name ManageSearchEngines.php

Thanks.

No idea, but this is the sort of thing that should be fixed in it.

ManageSearchEngines.php is in the Sources folder.

[vbgamer45]

Any idea why that breaks in MariaDB? Just curious

[Arantor]

Offset is a reserved word. Maria is doing the correct thing here, incidentally, by making it a reserved word after all.

LIMIT x, y is actually a shorthand MySQL introduced forever ago and that its popularity led other things (notably Postgres) to adopt it but it's not actually universal at all - and it's really a short form for LIMIT y OFFSET x.

(ANSI 92 SQL didn't cover this; MS SQL and Oracle don't even do LIMIT x, y in any fashion, you have to simulate it by way of using ROWNUM() to get the current row number and bodge it in the where clause. SQL:2008 did standardise this, but the official standard is something completely different.)

[vbgamer45]

Ah I see reserved word makes a lot more since since. I was worried for some reason that the AS statement was not allowed.

[pepf]

Thank you all for your help!

[pepf]

The OFFSET code change did not help. In the meantime I have found other links and function that are admin section internal that also do end in a domain not found message. The funny thing is that everything on the user side seems to be operating normally.

Tried to run repair_settings, but it also does not work. Everything in the test forum works normally. So, perhaps there is something broken in the files.

Question: is there a way to replace specific files that may involved without breaking the whole setup? Is moving the whole forum to another folder the best solution?

Thanks for any help.
Peter

[Kindred]

You can always re-upload a fresh set of files from the upgrade archive (not the install archive, because that would erase your Settings.php

[pepf]

Thanks for answering.
May ask what the Settings.php exactly does? Is it a global settings file or only for certain purposes within the whole? And, would any topics or dBs become unusable?

TIA, Peter

[Aleksi "Lex" Kilpinen]

Settings.php holds necessary settings for SMF to talk to your database, without it nothing works.

[Illori]

https://wiki.simplemachines.org/smf/How_to_upload_a_fresh_set_of_files

[pepf]

Thank you all for the information. I will try this and see if it resolves the problem.

Peter

[Doug Heffernan]

And, would any topics or dBs become unusable?

WHat do you mean by dBs? Did you mean the database? The answer to that is No. The topics, posts, members and all the other important file is stored in the database and not in the files. Overwriting the forum files, if done properly, will not affact the database. However if you have made manual changes to the  files, or you have mods that edit the files directly then all those changes they will be undone. So you might want to make a backup first of the files that have manual edits in them.