Periods in table names causing errors - sql

I am trying to update a table in pgadmin 3 (postgres 9.4) called: assay.Luminex.Luminex_GT_shared.Analyte
I kept getting the error:
ERROR: improper qualified name (too many dotted names):
assay.luminex.luminex_gt_shared.analyte
I have tested backquotes and brackets to no avail, keep getting syntax errors:
SELECT * FROM `assay.Luminex.Luminex_GT_shared.Analyte`;
SELECT * FROM [assay.Luminex.Luminex_GT_shared.Analyte];
I am a newb to SQL, I am just trying to make a simple update to a table and getting stuck on this.

As documented in the manual in SQL, non-standard identifiers have to be quoted with double quotes:
SELECT *
FROM "assay.Luminex.Luminex_GT_shared.Analyte";
But you should really avoid names like that.

Related

Column cannot be found or is not specified for query - Progress SQL Interface

I get the following error, I haven't had this issue before and was wondering if lvscat is an alias for something. From what I read that is a common issue, but even if it is that I am still unsure of how to fix it. This is the full Error
[DataDirect][OpenEdge JDBC Driver][OpenEdge] Column "LVSCAT" cannot be found or is not specified for query.
Here is the query:
INSERT INTO PUB.lvsbk (BookingNo, LvsCat)
VALUES (1007265, 'G')
Mapping with SQL Interface:
It is possible that the column was defined as "lvsCat". That means that the case is important.
Unfortunately, you have to use the double quotes to reference it:
INSERT INTO PUB.lvsbk (BookingNo, "LvsCat")
VALUES (1007265, 'G') ;
If this is the case, you might want to recreate the table without escaping the name of identifiers.
I am unsure what tool you are using to demonstrate the definition of your table, but you can view the actual definition of your table with:
select * from sysprogress.syscolumns where tbl = 'lvsbk';
Alternatively a simple:
select top 1 * from pub.lvsbk;
May provide enough evidence as to what your column is actually called.
I found the issue, it was because the field simply didn't exist.

How would I fix these "ORA-00933: SQL command not properly ended" "ORA-00923: FROM keyword not found where expected" errors?

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.

how to pull a column named "NUMBER" from Oracle through Ms Query in Excel

I know, I know...The column shouldn't be named "NUMBER", but it was here before I was, and I can't change it for now. At the moment, I only have read access to this database, and I was told it would be changed...soonish...
I've tried referencing it as Table."NUMBER" and that works when querying directly from Oracle, but for some reason, I still get the infamous ORA-01747: invalid user.table.column, table.column, or columns specification error when I reference it that way in MS Query. I also tried Table.""NUMBER"", "Table."NUMBER"", Table.'"NUMBER"', and 'Table."NUMBER"', but each of these gave me an error from MS Query saying it wasn't expecting the punctuation in the select column list.
Does this have something to do with the way MS Query handles double quotes? Is there any way to make sure that the double quotes around NUMBER make it to Oracle without MS Query throwing an error?
My query is really simple...except for this part.
Select Table."NUMBER"
From Table
Thanks in advance for any help.
try
SELECT table."NUMBER" AS a_number FROM table
or create a view referencing the table and rename the column as required
Aliases solve a lot of problems with names. I suspect that the issue you were having is not with running the query in Oracle but the result that comes back from Oracle. An alias allows the result set to be usable by Access.

Simple SELECT statement fails with "syntax to use near", "ORA-00906", "syntax error at or near" or "syntax near the keyword"

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]

Postgres Case Sensitivity

I have imported 100 of tables in Postgres from MSSql server 2008 through tool which created all the tables along with their columns in capital letter. Now if I want to make a data view from table e.g - STD_TYPE_CODES as-
select * from STD_TYPE_CODES
I am getting following error-
ERROR: relation "std_type_codes" does not exist
LINE 1: select * from STD_TYPE_CODES
^
********** Error **********
ERROR: relation "std_type_codes" does not exist
SQL state: 42P01
Character: 15
I know I can put the quotes around the table name as-
select * from "STD_TYPE_CODES"
But as I have worked with MSSql Server, there is no such kind of issue.
So is there any way to get rid of this? Please help.
In PostgreSQL unquoted names are case-insensitive. Thus SELECT * FROM hello and SELECT * FROM HELLO are equivalent.
However, quoted names are case-sensitive. SELECT * FROM "hello" is not equivalent to SELECT * FROM "HELLO".
To make a "bridge" between quoted names and unquoted names, unquoted names are implicitly lowercased, thus hello, HELLO and HeLLo are equivalent to "hello", but not to "HELLO" or "HeLLo" (OOPS!).
Thus, when creating entities (tables, views, procedures, etc) in PostgreSQL, you should specify them either unquoted, or quoted-but-lowercased.
To convert existing tables/views/etc you can use something like ALTER TABLE "FOO" RENAME TO "foo".
Or, try to modify dump from MSSQL to make it "PostgreSQL-compatible" (so that it will contain foos or "foo"s but not "FOO"s).
Either by explicitly editing dump file. (If you're using Linux, you can do sed -r 's/"[^"]+"/\L\0/g' dumpfile — however be warned that this command may also modify text in string literals.)
Or by specifying some options when getting dump from MSSQL. (I'm not sure if there are such options in MSSQL, never used it, but probably such options should exist.)