Thank you for the reports of blog issues. As far as I know, there were a couple of instances of weird page loads and “database connection” error messages. I suspect these were caused by server reboots or sommat at the host. I don’t see any strangeness about right now.
Even in small outfits, there are multiple servers to divide the workload not only work load balancing, but for segregation of roles (enhances manageability, security, scalability). These servers need to be synced to deliver the final product. When emergent maintenance (or poorly sequenced planned maintenance) disrupts the cooperation of these servers, the send error message back and forth.
You can only receive an error message from a server you can reach. Assume that when your request for a page goes across the internet, it is directed (eventually) to the web server where this blog is hosted. So the sequence goes from your computer, to a web server, to a database server, to a file server. There are different ways to set this stuff up, but for now, let’s roll with it: web server, database server, file server, and we’ll call them WX, DX, and FX. The web server WX is the public face of the thing, and is responsible for receiving your requests and assembling and sending the final product — a handsomely designed BDB page full of crunchy, valuable content — across the internet to your computer, so that you get the page you requested.
You can only receive an error message from a server you can reach. DNS servers along the way help navigate your way from your computer to WX. If you cannot reach WX, then you get timeouts (which is your computer giving up on the waiting game), spinning baloney, or DNS error messages. It depends what is causing your connection to WX to fail.
You can only receive an error message from a server you can reach. WX has a relationship with DX, the database server. If you can connect with WX, but WX cannot establish a connection with DX, you will get an error message like the one posted by Dime. Possible causes include the DX server being down, the password for WX to connect to DX having been changed, an incorrect time setting on both or either server involved (they compare times as well as passwords).
You can only receive an error message from a server you can reach. If DX, for some similar set of reasons, cannot connect to the file server FX, then you will get error messages like “resource unavailable.” If the fie server gets your request but the file has been deleted, renamed, moved, or is somehow unworthy to serve, you will get an error along the lines of “file not found”. And that is how you typically get the infamous “Error 404”, also known as a “Red X”.
So now you know one thing for sure: You can only receive an error message from a server you can reach. This blog uses a fairly cheap hosting arrangement. You get what you pay for. One of the consequences is an inability to use the .htaccess file, which would make “pretty” links available. Instead of finding a page at balldiamondball.com/blog/post/what-the-fork.php, we are limited to using balldiamondball.com/blog/1234.php or sommat. More on this another day. Another consequence is a low number of nines on the uptime. If you are TacoHut.com, selling tacos online, you pay through the nose and you get 99.9999 percent uptime (0.999999 out of the perfect one, or six nines). This blog on the other hand will accept a ludicrously low number of nines, commonly described as “best-effort”. They do their best, and I take their word for it. Sometimes when a server is unavailable, misconfigured, or not synced with its neighbors, the website will either not be available at all, or will deliver the wrong content, or no content at all (you get the page, but it’s missing things).
You good people deserve an explanation. TL;DR, bit happens.