sorry, I really don't see it.
I have a mysqli syntax like this:
"UPDATE table
SET
used='1',
ip='".mysqli_real_escape_string($connection,$_SERVER['REMOTE_ADDR'])."',
when=NOW()
WHERE
uid='x3'"
This is my error:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near
when=NOW()
WHERE
uid='x3'' at line 6
WHEN is a reserved word in MySQL. If you wish to use it as a column name you must surround it in backticks.
In other words, replace
when=NOW()
with
`when`=NOW()
Related
This error 'the cursor is open' took me some hours to resolve, so I submit here the explanation in order to propose a solution for people experiencing the same problem.
Problem description : trying to get data from postgreSQL through standard function SQLEXEC raised "Syntax Error", while the same query runs correctly on PGAdmin. Morecover, subsequent queries systematically raised "The cursor is open" (each time being necessary to kill Postgres process AND to reinit the VFP connexion).
Conditions: Postgres 9.3.3, Windows XP SP2, PostgreSQL ODBC Driver(UNICODE) version 9.02.01.00, Visual FoxPro 9 SP1
Solution: SQLExec 3rd parameter should not contain a dot ("."). For example, the command SQLExec(1, 'Select 1', '.F.') raises the problem, when SQLExec(1, 'Select 1', 'F') does not.
In my case '.F.' value was generated programmatically, which made the diagnosis difficult.
That is not a VFP error bur programmer's error. The 3rd parameter is a cursor name for the result and as said in the documentation a cursor name cannot have dot. OTOH 'F' is a valid cursor name.
As per the syntax error, very likely you were trying to pass a long sql string literal over 255 characters but can't be sure as we don't see your code. In VFP it is also documented that character literals cannot exceed 255 in length.
I have the following select statement:
select * from '/MOUNT_NAME/DB_NAME/TABLE_NAME'
Where MOUNT_NAME, DB_NAME, TABLE_NAME are just what they say they are.
The above syntax works just fine in the generated SQL statement when first opening a notebook and exploring the data. However, when I type in the same thing in a SQL window created in that notebook I get the following error:
operator '(' expected; '/MOUNT_NAME/DB_NAME/TABLE_NAME'
Any suggestions? Am I misusing the Notebook behavior for writing just simple syntax? Must be doing something wrong since this seems so straightforward. Any clarification out there?
The correct query would be:
SELECT * FROM `/MOUNT_NAME/DB_NAME/TABLE_NAME`
Note the use of back-ticks (not single quotes) to escape identifiers, which changed recently when SlamData was updated to use the latest version of Quasar. It looks like not all documentation on the SlamData website has been updated yet.
For ex, I have a query in postgreSQL such that "product_version=:productVersion".
It's giving me a syntax error.
It's giving you a syntax error because it makes no sense as SQL, and is invalid syntax.
(Please always show the exact text of error messages*)
Since inserting the string literal :productVersion doesn't make much sense, e.g.
product_version=':productVersion'
you might be using the psql command line client and trying to substitute a client variable. If so, you need to use a quoted substitution, e.g.:
product_version=:'productVersion'
but this only works for psql. Not Rails and the Pg gem, not JDBC, not PHP, not psycopg2, nothing but psql.
If that's not what you meant, then either you are using a programming language with placement parameters and using the wrong parameter syntax for your language, or you are attempting to use the psql command line client's variable substitution and aren't using psql. Impossible to guess what you mean unless you specify the language/tools used.
Look up the placement parameter syntax for your programming language and database driver. Make sure you're using the right one.
I have a very simple query:
DROP TYPE IF EXISTS abc;
When run on my local machine, all good. When run on my production machine, it returns:
ERROR: syntax error at or near "EXISTS" at character 14
I have tried typing it manually rather than copying to make sure there is no hidden character somewhere, but I can not figure out how this can given an error at one place but not at another.
Check the versions that you're using, for both local and production.
The if exists clause was only added to drop type in 8.2.
And, before anyone questions why it complains about the exists rather than the if, it's because the statement:
drop type if
is perfectly valid up to that point, as an attempt to drop the if type. It's only the exists after that which makes the syntax bad.
I am retrieving the following sql statement from a table and then using bind variables to substitute the values in. I get a syntax error when running the statement. It seems to be occurring as a result of the lower() function however I believe I am using this correctly. I have tried running the statement manually via psql and it works fine with the values I provide. Does anyone have any ideas on this one? I have tried switching the ' for $$ but this had no effect.
statement
SELECT column_name
FROM information_schema.columns
WHERE table_name=lower(':1')
and column_name=lower(':2')
expected basic statement with substituted values
SELECT column_name
FROM information_schema.columns
WHERE table_name=lower('MyTableName')
and column_name=lower('MyColumnName')
statement run by postgresql
SELECT column_name
FROM information_schema.columns
WHERE table_name=lower('((E'RWOL_TMA_ROADWORKS'))')
and column_name=lower('((E'TPHS_CWAY_RESTRICT_TYPE'))')
Error in C#
ERROR: 42601: syntax error at or near \"MyTableName\"
Error in PostgreSQL log file
2012-04-16 11:36:15 BST ERROR: syntax error at or near "RWOL_TMA_ROADWORKS" at character 80
2012-04-16 11:36:15 BST STATEMENT: SELECT column_name FROM information_schema.columns WHERE table_name=lower('((E'RWOL_TMA_ROADWORKS'))') and column_name=lower('((E'TPHS_CWAY_RESTRICT_TYPE'))')
EDIT: Retrieval and implementation code is written in C#. I use the database connection base classes and the npgsql provider factory in order to make connections, run queries and retrieve the data. This method works for all other queries that use this method of binding variables etc apart from this one where I try to use the lower() function.
EDIT: I have tried removing the quotes altogether to let the binding agent deal with quoting the values and this provided the same syntax error.
EDIT: Have now enabled logging and added the actual statement that postgresql is running.
I think vyegorov is on the right path - there's something funny with your placeholders.
I don't think your second example is the actual query after substition because that doesn't contain any errors. Where did it come from and why aren't you providing the actual query - do you have statement logging turned on in PostgreSQL?
Also, I'm suspicious of the syntax error - what's going on with the escaped double-quotes? Are they actually double-quotes and not doubled-up single quotes?
Are you sure you need single-quotes around your placeholders? Usually the drivers manage that for you.
Are you sure you aren't double-quoting the values anywhere?
Get the actual SQL and look at the quoting and the problem will be obvious I suspect.
UPDATE: now have SQL
Here's the error in the posted statement:
lower('((E'RWOL_TMA_ROADWORKS'))')
You've got two levels of quotes here. Remove the ones you've added and we should end up with something like:
lower((E'RWOL_TMA_ROADWORKS'))
Ignoring the repeated brackets that's valid (The E'...' is the syntax for a c-style escaped string - google around standard_conforming_strings).
Maybe you shouldn't use quotes around :1 and :2. Most APIs that support bind variables will correctly quote the value for you.
I think that it is not lower() functions' issue, but rather bind variable processing issue.
As #Adrian suggests, try not to use quotes around your bind variables.
And you should also consult your databases logs, you'll see more information there about what's going on.
EDIT: Use:
SHOW data_directory;
SHOW log_directory;
SQL statement to find the locations of your DATA directory and logs location, if logs path is relative, then it will be relative to the DATA directory.
Go there and find the recently modified file, check the contents. You should see the error message with default PostgreSQL configuration.
And it'd be good for you to enable debugging also on the middleware / factory levels.