i was able to get the view page to display red, but could not get the audio file to play (probably a browser permission or timing issue.) i recommend adding logging code in both the alert and alert_generate files, with datetime, file, and action being performed so that you can see what the code is actually doing.
for what this code is doing, there's about three times too much code and most of the markup is out of date, and even when it wasn't there's a huge amount of broken html present. if you rewrite it, the major things that will simplify it are -
put the form processing code and the form on the same page.
there's no need for the alert.php file, the ajax request to it, and requesting it when the submit button is pressed (which doesn't even mean that the form got submitted.) at the point of successfully completing the post method form processing code, you would set the alert status flag in the row in the alert database table.
there's also no need for the alert_generate.php file and the ajax requests to it at 300 millisecond intervals. you are already causing the view page to be periodically reloaded. if the alert status flag is set when the page is requested, just output the markup needed to cause the page to display red, play the audio file, and reset the alert status flag.
as already stated, put the database connection code into a separate .php file and require it when needed. switching to the much simpler and more modern PDO extension will simplify all the database code.
the only time handling database statement errors in your application code will do any good are for user recoverable errors, such as when inserting/updating duplicate or out of range user submitted values. since you are not dealing with these (you should use a run-once token to prevent multiple form submissions), there's no need for any database error handling logic in your code. just use exceptions for database statement errors and let php catch and handle any exception, where php will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.)
the code for any web page should be laid out in this general order (this would apply to the form processing/form page and the view page) -
initialization
post method form processing
get method business logic - get/produce data needed to display the page
html document
the form processing/form page should -
detect if a post method form was submitted.
keep the form data as a set in a php array variable, then operate on elements in this array throughout the rest of the code, i.e. don't write out lines of code copying each form field to other variables for nothing.
trim all the input data before validating it. after you do item #2 on this list, you can accomplish this with one line of code.
validate all the inputs at once, storing validation errors in an array using the field name as the array index. note: there is no 'song' field in the form and those lines of code you have for it in the form processing code are/should be producing php errors.
after the end of all the validation logic, if there are no errors (the array holding the errors will be empty), use the form data.
use a prepared query when supplying external, unknown, dynamic values to the query when it gets executed.
after using the form data (since that code could produce additional errors, if there are no errors, perform a redirect to the exact same url of the current page to cause a get request for the page.
to display a one-time success message, store it in a session variable, then test, display, and clear the session variable at the appropriate location in the html document.
it is at this point where you would set the alert status flag in the alert database table.
if there are errors at step #5 or #7, the code will continue on to display the html document, display any errors, redisplay the form, populating the field values with the existing data.
any value you output in a html context should have htmlentities() applied to it to help prevent cross site scripting.
you should validate the resulting web pages at validator.w3.org