Join | Technology Tales

TOPIC: JOIN

Dealing with Error 1064 in MySQL queries

27^th April 2023

Recently, I was querying a MySQL database table and got a response like the following:

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use

The cause was that one of the data column columns was named using the MySQL reserved word key. While best practice is not to use reserved words like this at all, this was not something that I could alter. Therefore, I enclosed the offending keyword in backticks (`) to make the query work.

There is more information in the MySQL documentation on Schema Object Names and on Keywords and Reserved Words for dealing with or avoiding this kind of situation. While I realise that things change over time and that every implementation of SQL is a little different, it does look as if not using established keywords should be a minimum expectation when any database tables get created.

ERROR: Ambiguous reference, column xx is in more than one table.

5^th May 2012

Sometimes, SAS messages are not all that they seem, and a number of them are issued from PROC SQL when something goes awry with your code. In fact, I got a message like the above when ordering the results of the join using a variable that didn't exist in either of the datasets that were joined. This type of thing has been around for a while (I have been using SAS since version 6.11, and it was there then) and it amazes me that we haven't seen a better message in more recent versions of SAS; it was SAS 9.2 where I saw it most recently.

proc sql noprint;
    select a.yy, a.yyy, b.zz
        from a left join b
            on a.yy=b.yy
                order by xx;
quit;

ERROR: Invalid value for width specified - width out of range

8^th June 2010

This could be the beginning of a series of error messages from PROC SQL that may appear unclear to a programmer more familiar with Data Step. The cause of my getting the message that heads this posting is that there was a numeric variable with a length less than the default of 8, not the best of situations. Sadly, the message doesn't pinpoint the affected variable, so it took some commenting out of pieces of code before I found the cause of the problem. That's never to say that PROC SQL does not have debugging functionality in the form of FEEDBACK, NOEXEC, _METHOD and _TREE options on the PROC SQL line itself or the validation statement, but neither of these seemed to help in this instance. Still, they're worth keeping in mind for the future, as is SAS Institute's own page on SQL query debugging. Of course, now that I know what might be the cause, a simple PROC SQL report using the dictionary tables should help. The following code should do the needful:

proc sql;
    select memname, name, type, length
        from dictionary.columns
            where libname="DATA" and type="num" and length ne 8;
quit;

Login Logger plugin

20^th July 2007

The Login Logger WordPress plugin sounds like a great idea and works fine with standard situations. However, go beyond these and things start to go awry. An example is where you have to use unique database table prefixes because you use shared hosting. This is certainly something that I do and it breaks Login Logger. Thankfully, the fix for this is easy enough: just amend the database query on line 22 in the manage.php file as follows:

Before:

$query = "SELECT distinct wp_users.user_login,".$table_name.".username FROM wp_users LEFT OUTER JOIN ".$table_name." ON wp_users.user_login = ".$table_name.".username WHERE ".$table_name.".username IS NULL";

After:

$query = "SELECT distinct " . $table_prefix . "users.user_login,".$table_name.".username FROM " . $table_prefix . "users LEFT OUTER JOIN ".$table_name." ON " . $table_prefix . "users.user_login = ".$table_name.".username WHERE ".$table_name.".username IS NULL";

The issue was caused by hard-coding of the table prefix for the user table, and using the prefix that you yourself have set is the way out of this. What is less easy to resolve is a conflict between the Login Logger and Themed Login plugins. That will take further investigation before I come up with a fix.