Simple Machines Community Forum

SMF Support => SMF 2.0.x Support => Topic started by: Cola-Coca on August 08, 2024, 11:17:40 PM

Title: Datebase error after switching to a new server
Post by: Cola-Coca on August 08, 2024, 11:17:40 PM
Helo,

When I transferred everything to the new server, datebase and files, when I want to make a new post, I get this error:

Database Error
Field 'ua_os' doesn't have a default value
File: /public_html/Sources/Subs-Post.php
Line: 1855


I didn't have this problem on the old server, everything worked correctly.
I didn't change or touch anything, I transferred the files to the new server and uploaded the database. I tried to delete all 'ua_os' column via phpmyadmin (smf_messages -> Structure) but it didn't help me. As I already wrote, I did not touch anything, I just moved the forum to a new server and when I make a new post I get that error.

I looked at line 1855 on Subs-Post.php and I can't find what the problem is, in attachemnt I leave mine Subs-Post.php , if someone can help me, I would be grateful.
Title: Re: Datebase error after switching to a new server
Post by: Sir Osis of Liver on August 08, 2024, 11:38:31 PM
Not on my computer, but that looks like a mod error.  New server may be running a different php version than old, 2.0.19 supports up to php 8.0, some older mods do not.  You can fix that error by assigning default value NULL to that field.
 
Title: Re: Datebase error after switching to a new server
Post by: Sesquipedalian on August 09, 2024, 12:27:07 AM
That error is from leftover data from an old mod. Please see this topic for help fixing it: https://www.simplemachines.org/community/index.php?topic=581746.0
Title: Re: Datebase error after switching to a new server
Post by: Kindred on August 09, 2024, 12:52:41 AM
It's not the php version... it's the mysql version.  Newer versions require defaults to be set.

You need to either set the default (usually null, as mentioned) or remove the table/field if you no longer use the mod
Title: Re: Datebase error after switching to a new server
Post by: Cola-Coca on August 09, 2024, 02:47:14 PM
Quote from: Kindred on August 09, 2024, 12:52:41 AMIt's not the php version... it's the mysql version.  Newer versions require defaults to be set.

You need to either set the default (usually null, as mentioned) or remove the table/field if you no longer use the mod

Helo,

The Php version is the same, the only difference is in the MySQL version. The old server has an older version of mysql while the new server has a newer version.

I deleted the tables/fields that have to do with that mod because I don't use that mod.



After that, I get the following error when I go to create a new post:

Data too long for column 'poster_name' at row 1
File: /public_html/Sources/Subs-Post.php
Line: 1855


Table/field with a name 'poster_name' is located inside 'smf_messages' table.
Here you can see how it is set:

Img Link: https://i.imgur.com/D47MQMl.png

I really don't understand why I have this problem now after deleting 'ua' tables/fields ?
On the old server with the old mysql, everything worked fine.
Title: Re: Datebase error after switching to a new server
Post by: Doug Heffernan on August 09, 2024, 03:13:42 PM
Quote from: Cola-Coca on August 09, 2024, 02:47:14 PMData too long for column 'poster_name' at row 1
File: /public_html/Sources/Subs-Post.php
Line: 1855


Table/field with a name 'poster_name' is located inside 'smf_messages' table.
Here you can see how it is set:

Img Link: https://i.imgur.com/D47MQMl.png (https://i.imgur.com/D47MQMl.png)

I really don't understand why I have this problem now after deleting 'ua' tables/fields ?
On the old server with the old mysql, everything worked fine.


Set the length value to 255 and save the changes. i.e. replace 0 with 255. That should fix the error.
Title: Re: Datebase error after switching to a new server
Post by: Cola-Coca on August 09, 2024, 03:31:15 PM
Quote from: Doug Heffernan on August 09, 2024, 03:13:42 PM
Quote from: Cola-Coca on August 09, 2024, 02:47:14 PMData too long for column 'poster_name' at row 1
File: /public_html/Sources/Subs-Post.php
Line: 1855


Table/field with a name 'poster_name' is located inside 'smf_messages' table.
Here you can see how it is set:

Img Link: https://i.imgur.com/D47MQMl.png (https://i.imgur.com/D47MQMl.png)

I really don't understand why I have this problem now after deleting 'ua' tables/fields ?
On the old server with the old mysql, everything worked fine.


Set the length value to 255 and save the changes. i.e. replace 0 with 255. That should fix the error.

I did that and now I get an error when I want to make a new post:

Field 'bumped_time' doesn't have a default value
File: /public_html/Sources/Subs-Post.php
Line: 1890


Probably now this error is related to the 'bump this topic' ?
Title: Re: Datebase error after switching to a new server
Post by: Doug Heffernan on August 09, 2024, 04:22:10 PM
Quote from: Cola-Coca on August 09, 2024, 03:31:15 PMProbably now this error is related to the 'bump this topic' ?

That't correct.
Title: Re: Datebase error after switching to a new server
Post by: Cola-Coca on August 09, 2024, 10:51:56 PM
Quote from: Doug Heffernan on August 09, 2024, 04:22:10 PM
Quote from: Cola-Coca on August 09, 2024, 03:31:15 PMProbably now this error is related to the 'bump this topic' ?

That't correct.

Thank you all for your time and help to solve this problem.
I uninstalled the mod 'Bump This Topic' and the error 'bumped_time' was solved.
After that I installed again the mod 'Bump This Topic' and now everything works as it should.

It's strange that the version of MySql caused such a problem.
Title: Re: Datebase error after switching to a new server
Post by: shawnb61 on August 10, 2024, 02:19:59 AM
The newer versions of mysql enforce stricter standards & best practices by default.

You can either override those defaults to make it easier to do questionable stuff (like not provide defaults), or, just follow better practices.  The latter is preferred.
Title: Re: Datebase error after switching to a new server
Post by: Doug Heffernan on August 10, 2024, 03:11:22 AM
Glad to see that it has been fixed @Cola-Coca. Marking this as solved.