If you’re getting an error that reads “function array_sample(integer, integer) does not exist” when using the array_sample() function in PostgreSQL, it’s probably because your first argument is not an array. In particular, this specific error message implies that the first argument is an integer.
The first argument for this function must be an array.
To fix this error, be sure that your first argument to array_sample() is an array, not an integer.
If you’re getting an error that reads something like “ERROR 1539 (HY000): Unknown event ‘Event1’” in MySQL when trying to drop an event, it’s probably because the event that you’re trying to drop doesn’t exist.
There are a couple of ways to address this issue. One way is to use the IF EXISTS clause so that dropping a non-existent event doesn’t cause an error. Another way is to check the name of the event that you’re trying to drop – it could be that you’re using the wrong event name.
If you’re getting an error that reads “ERROR 1229 (HY000): Variable ‘event_scheduler’ is a GLOBAL variable and should be set with SET GLOBAL” in MySQL, it’s probably because you’re trying to set the event_scheduler system variable, but you’re not specifying it as a global variable.
The event_scheduler variable is a global variable and so we must specify it as a global variable.
To fix this issue, specify it as a global variable when setting it’s value.
Continue readingIf you’re getting an error that reads “Failed to generate invisible primary key. Column ‘my_row_id’ already exists“, it’s probably because you’re trying to create a table without a primary key, and you’ve named a column my_row_id.
When your system has generated invisible primary keys (GIPKs) enabled, and you create an InnoDB table without explicitly defining a primary key, MySQL automatically creates an invisible column called my_row_id and creates a primary key constraint against it. This is called a generated invisible primary key.
However, if you name one of your columns my_row_id, then MySQL can’t create the GIPK due to the column already existing.
There are several ways to go about fixing this issue.
Continue readingIf you’re getting an error that reads something like “Multiple primary key defined” in MySQL, it’s probably because you’re defining more than one primary key to a table.
A table can only have one primary key in MySQL.
It’s possible that you were trying to create a composite primary key (i.e. a primary key consisting of multiple columns), in which case, you can fix the issue with a simple modification to your code.
Otherwise, you will need to decide which column should be the primary key for the table and only apply the PRIMARY KEY definition to that column.
If you’re getting an error in MySQL that reads something like “Duplicate entry ‘1’ for key ‘person.PRIMARY’” when trying to add a primary key to an existing table, it’s probably because the table already contains duplicate values in the column you’re trying to add the primary key to.
When we add a primary key to an existing table, we need to make sure that the column/s that we’re adding the primary key to contains unique values across all of its rows.
One way to fix this issue is to create a composite primary key (one that’s defined across multiple columns). Another way to fix it is to change the values so that they’re all unique. Another option is to apply the primary key to a different column altogether (i.e. one that contains unique values).
Continue readingIf you’re getting an error that reads “A table must have at least one visible column” in MySQL, it could be that you’re trying to create a table with nothing but invisible columns. Or you could be altering an existing column to be invisible, but it would leave the table with nothing but invisible columns.
To fix this issue, be sure to have at least one visible column in the table.
Continue readingIf you’ve been using EXPLAIN ANALYZE to analyse your MySQL queries, you may have encountered a little quirk regarding the output format: When we explicitly use FORMAT=TRADITIONAL in our EXPLAIN ANALYZE statement, we get an error. But when our explain_format system variable is set to TRADITIONAL we don’t get an error.
What’s going on with that? Is this a bug?
First up, no it’s not a bug. It can all be explained by the way EXPLAIN ANALYZE handles our explain_format setting.
If you’re getting an error that reads “This version of MySQL doesn’t yet support ‘EXPLAIN ANALYZE with JSON format’” in MySQL, it’s probably because you’re trying to run EXPLAIN ANALYZE with the wrong output format.
The EXPLAIN ANALYZE statement only supports the TREE output format. However, there are a few things to be aware of regarding this.
Either way, the quickest way to fix the error is to use FORMAT=TREE in your EXPLAIN ANALYZE statement.
If you’re getting an error that reads “This version of MySQL doesn’t yet support ‘EXPLAIN ANALYZE FOR CONNECTION’” in MySQL, it’s probably because you’re trying to use the FOR CONNECTION option with EXPLAIN ANALYZE, but EXPLAIN ANALYZE doesn’t support the FOR CONNECTION option.
It’s true that we can use the FOR CONNECTION option with the EXPLAIN statement, we can’t use it when using the ANALYZE variant of EXPLAIN (we can use EXPLAIN with or without ANALYZE). At least, this is how it works as of this writing (MySQL 8.3).
To fix, either remove the ANALYZE keyword from the statement or don’t use the FOR CONNECTION option.