Workaround for 'Sorry, SMF was unable to connect to the database'?

[W7 riso]

Found a very simple workaround for "Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later."
Look for /Sources/Subs-Db-mysql.php and replace this file with Sources/Subs-Db-mysql.php~ and rename Subs-Db-mysql.php~ to Subs-Db-mysql.php and your Forum will be running fine again.
Note the file used to replace the new 2.0.14 file is version 2.0.9 used by Smf 2.0.13 but all works fine on Smf 2.0.14 no errors so far.
I know it's perhaps not the best way to get a Forum running again but I've saved a lot of time and it's an easy fix.
Btw in my case PHP Version is 5.3.25



Topic split from this one ~ Steve

[Illori]

that does not solve the issue, and puts you in a state of having mixed files, you should never just revert some and not all files. you also need to upgrade your php install to php 5.4 or higher to work with the patch.

[W7 riso]

Illori,

I know it's not the nicest solution.
It solved the issue here, mixed files: just one!
My php is at the host (shared server) they don't want to upgrade php just for me so I'm not able to upgrade to 5.4 in my case this little file replacement was the last resort and all works fine again.

[Illori]

then i would look for a new host rather then cause the mess you have.

[Kindred]

More importantly, that version of PHP is no longer supported and has not been for a long time. Seriously get a host who can use modern versions of services not outdated unsupported versions

[tinoest]

More importantly, that version of PHP is no longer supported and has not been for a long time. Seriously get a host who can use modern versions of services not outdated unsupported versions

But php 5.3 is not unsupported on Redhat/CentOS 6 and won't be until 2020!


So I would say if the host is using that package they are sticking with something which is secure and stable.

[Arantor]

It's unsupported by PHP themselves and has been for a long time now. Just because RH/CentOS are backporting fixes, doesn't mean it's *actually* supported.

[tinoest]

It's unsupported by PHP themselves and has been for a long time now. Just because RH/CentOS are backporting fixes, doesn't mean it's *actually* supported.

I'd argue it's still supported for security updates. Saying that it's unsupported and the host is using outdated version so is wrong as it's the default still. I know SCL provides 5.6 and is also supported by RedHat.

Same as SMF 2.0, the idea with those are you don't break backwards compatibility, numerous businesses pay RedHat a fair amount of money for that privilege.

[Arantor]

Thing is, I recently went looking around for versions of PHP that seem to be supported; almost nowhere I could find as a hosting company actually offered below 7.0... the one company I did find that didn't support 7.0 yet was GoDaddy, everyone else seems to offer it.

The other thing is, it's not possible to know in all cases if the package is actually up to date and supported or not because it could be 5.3.29 or 5.3.29-with-all-the-backport-fixes and we'd have no reliable way to determine this.

Not to mention that most users aren't as technical and giving them information like this will confuse and likely cause trouble far more than simplifying the situation to a reasonable safe position.

[tinoest]

Thing is, I recently went looking around for versions of PHP that seem to be supported; almost nowhere I could find as a hosting company actually offered below 7.0... the one company I did find that didn't support 7.0 yet was GoDaddy, everyone else seems to offer it.

The other thing is, it's not possible to know in all cases if the package is actually up to date and supported or not because it could be 5.3.29 or 5.3.29-with-all-the-backport-fixes and we'd have no reliable way to determine this.

Not to mention that most users aren't as technical and giving them information like this will confuse and likely cause trouble far more than simplifying the situation to a reasonable safe position.

I would say to simplify the situation it would be better to not run the upgrader if the version was less than PHP 5.4 rather than upgrade then have issues.

Also its not like php doesn't have functions built in to it which allow you to check the version and also if the function itself actually exists, but we are digressing.

The falacy that PHP 5.3 this unsupported was my point. It is supported by RedHat and its derivatives.

PHP 5.3 is unsupported by the PHP development team who add new features to PHP.

[Arantor]

It's actually supposed to check, except it checks for 5.3 instead of 5.4.

And I'm not disputing that it is not supported in some fashion - merely that for ease of explaining it to people who probably don't get what supported-by-RedHat entails, the explanation is deliberately simplified to the point of being inaccurate so that we can give simpler-to-follow advice, even if we know full well it isn't technically accurate. Advice people can follow is better than technical accurate advice that is too difficult for most people to follow.

[tinoest]

Then I would suggest it would be more prudent to state that then have a outright attack at host. ( I'm not suggesting it was you who did attack the host. )

As they could be providing support quite correctly for the OS utilised on the server.

[Arantor]

I guarantee you taking that stance would confuse most of the people who come here, especially as there are few reasons to continue running 5.3 anyway at this point in time.

Even GoDaddy supports 5.6 these days and is the only big host I could find that doesn't support PHP 7.

[tinoest]

I just agreed that you can say php 5.3 is not supported by SMF, what I disagreed with was the way it was conveyed.

If as a forum you'd prefer to be aggressive towards people who can't defend themselves then that's fine. I however believe that isn't the correct way to be.

[W7 riso]

@tinoest,
Totally agreed with your remark, it felt unpleasant to read the re: I only tried to help some fooks!.
Have to tell all respondents here there are Smf users who ran into the same position after the 2.0.14 upgrade and lost their forum(s) all what was left for them: "Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later."
So after spending some hours and finding no solution on the net I found a simple way by replacing and rename the old file~ to file, the whole issue with Php lower 5.4 (what's causing a forum breakdown) is the non-compability in this Subs-Db-mysql.php file by replacing the latest file by the former Subs-Db-mysql.php~ file people might get access again to their forum(s).
Btw this issue occurred only on a test forum hosted by a cheap host so for me no big prob.
For the main forums I use I'm on my own dedicated IIS server using all latest so no compability issues what so ever.