According to Oracle documentation for statement SELECT it should be possible to alias table names with aliases without or with keyword AS. However, aliasing tables with keyword AS leads to error:
ORA-00933: SQL command not properly ended
For example, the following statement fails with the above error:
SELECT COUNT(*) FROM MY_TABLE AS A;
Once keyword AS is removed it executes as expected.
Could anyone please comment on this. Is there a way to make the application of AS for table aliasing work?
P.S. I'm using a code generation utility that translate some Java code into SQL statements at runtime. This utility enforces the use of aliases with AS.
Oracle does not accept AS for table aliases and I see no way to make it work.
Can't you do anything in Java? AS for column aliases is optional in Oracle, so you could look for all " AS " in the generated string and remove them (thus removing AS for column aliases as well as for table aliases). Is this an option?
Related
This Statement:
SELECT id, units, cost FROM inventory_list WHERE cost <= 20;
Gives me:
ORA-00923: FROM keyword not found where expected
While this statement:
SELECT * FROM items WHERE ilt_id = 'il010230126' OR ilt_id = 'il010230128';
Gives me:
ORA-00933: SQL command not properly ended
Not sure about this and may be version dependent (below link is for oracle 10g... but you can see on this site
https://docs.oracle.com/cd/B19306_01/em.102/b40103/app_oracle_reserved_words.htm
That cost is an oracle reserved keyword, so it is not wise to use it as a column name.
If you have no control of the table I think you may be able to surround it in double quotes eg select "COST" to avoid oracle picking it up as a reserved word.
By default Oracle creates fields in uppercase so the field name will need to be in uppercase unless when the table was created it was forced into different case by surrounding it in Quotes.
Check that you don't have invisible characters in your file and that you're using the right encoding. I sometimes accidentally introduce them because I have a non english keyboard map and accidentally hit the wrong key combination.
Just type again one of your SQL statements and test them.
Current Environment: Split Access Database, Local Access Front End, Access Backend on shared network drive
I'm writing a stupid long SELECT statement. Using table aliases to makes my code more readable.
I was taught to write out full table names in WHERE statements because they are executed before the FROM statement. However, when I did that - Access isn't finding the table / field referenced when I write the full table name out. Strangely, I tried using the alias in the WHERE statement and it works!!?
Does Access execute the statement differently than I was taught? Or am I unknowingly causing it to do it this way?
Shortened version of my SQL code that doesn't work:
SELECT [C].Multi_File_Case_ID,
[C].Case_Report_Number,
[C].Include_In_Casebook,
[C].Case_Status,
FROM Case_Tbl AS [C]
WHERE [Case_Tbl].Include_In_Casebook = True;
Edit: A word and a capitalization ;)
Once you define a table reference as an alias in the FROM, you need to use that alias everywhere in the query. The alias is more than a nickname; it is a name change for the scope of the query.
I would advise you to drop the square braces. Queries are easier to read and write as:
SELECT c.Multi_File_Case_ID, c.Case_Report_Number, c.Include_In_Casebook, c.Case_Status
FROM Case_Tbl AS c
WHERE c.Include_In_Casebook = True;
When you do not define a table alias, the table name itself serves as the alias.
I'm reading sql code which has a line that looks like this:
SELECT INTO _user tag FROM login.user WHERE id = util.uuid_to_int(_user_id)::oid;
What exactly does this do? The usual way to use SELECT INTO requires specifying the columns to select after the SELECT token, e.g.
SELECT * INTO _my_new_table WHERE ...;
The database is postgresql.
This line must appear inside of a PL/pgSQL function. In that context the value from column tag is assigned to variable _user.
According to the documentation:
Tip: Note that this interpretation of SELECT with INTO is quite different from PostgreSQL's regular SELECT INTO command, wherein the INTO target is a newly created table.
and
The INTO clause can appear almost anywhere in the SQL command. Customarily it is written either just before or just after the list of select_expressions in a SELECT command, or at the end of the command for other command types. It is recommended that you follow this convention in case the PL/pgSQL parser becomes stricter in future versions.
I have a very simple SQL statement
SELECT * FROM Table;
but, my query engine returns a syntax error. Why?
Error Details:
An unhandled exception of type 'System.Data.SqlClient.SqlException' occurred in >System.Data.dll
Additional information: Incorrect syntax near the keyword 'Table'.
How is this possible? I checked the connection string and it is correct.
I checked my table name and it is also correct.
What I am doing wrong?
Okay, Table is a reserved keyword in all variants of SQL.
If you want to call a table Table, and use it in a statement, you have to tell your sql engine that it is an identifier. To do this you need to use Identifier Qualifiers.
for (MS SQL Server) TSQL use square brackets
SELECT * FROM [Table];
for MySQL use `
SELECT * FROM `Table`;
for Oracle and PostgreSQL use quotation marks,
these are standards compliant.
SELECT * FROM "Table";
for SQLite you can use any of the above, but quotation marks are prefered.
The Identifier Qualifiers tell the engine that this is an identifier (the name of an object.) Not the name of a keyword, even if they happen to be the same. Without your guidance the query engine can get confused and report an error, or worse, do something unexpected.
Using Identifier Qualifiers is good practice, even if the identifers are not keywords.
They better define statements for all parsers, including the fleshy kind.
Naming objects after keywords is generally considered bad practice. So you should try to avoid making identifers the same as keywords. The occasions when a reserved keyword is descriptive of the contents of a table are rare, see the footnote.
e.g. your table is not a Table of tables.
The problem and advice is not limited to Tables, Identifiers are required for all database objects inluding Schema, Views and the many types that exist, standard and vendor-specific.
Another form of good practice is to prefix Table indentifiers with a Schema identifier, this helps the query engine a little.
When including the Schema identifier, the identifer should be qualified,
for (MS SQL Server) TSQL use square brackets
SELECT * FROM [dbo].[Table];
for MySQL use `
SELECT * FROM `dbo`.`Table`;
for Oracle, PostgreSQL and SQLite use quotation marks
SELECT * FROM "dbo"."Table";
even if your Schema is not named after a keyword, as should be the case.
For your reference, to help you avoid conflicts.
A list of TSQL Reserverd Keywords.
A list of MySQl Reserved Keywords.
A list of Oracle Reserved Keywords.
A list of SQLite Reserved Keywords.
A list of PostgreSQL Reserved Keywords.
Notable "gotcha's" include USER and ERROR, which seem to come up when designing systems.
Footnote:
There are occasions when using reseved words for object names may be semantically correct.
Consider the contrived example of an information system for a furniture shop. In this scenario, a table of tables (kitchen, garden, dining, apothecary etc.) may be correct. So, you could argue Table was the correct identifier.
If you always use Identifier Qualifiers, you won't get burned.
If you are using SQL server you need to wrap table in brackets [] as table is keyword in SQL Server
SELECT * FROM [Table]
I'm attempting to write an extension for SQL Developer to better support Postgres. These are just XML configuration files with SQL snippets in them. To display the values for a postgres sequence, I need to run a simple query of the following form:
select * from schema.sequence
The trouble with this is that the Oracle SQL Developer environment provides the correct schema and node (sequence) name as bind variables. This would mean that I should format the query as:
select * from :SCHEMA.:NAME
The trouble with this is that bind variables are only valid in the select clause or the where clause (as far as I'm aware), and using this form of the query returns a "syntax error at or near "$1" error message.
Is there a way to return the values in the sequence object without directly selecting them from the sequence? Perhaps some obtuse joined statement from pg_catalog tables?
Try this:
select *
from information_schema.sequences
where sequence_name = :name
and sequence_schema = :schema;
It's not exactly the same thing as doing a select from the sequence, but the basic information is there.