The issue is when querying a table created using Aqua Data Studio in our IBM DB2 database, column names can't be specified unless I use the system name. Tables made a short time ago don't have this issue. The query can find the column names just fine in them. There also is not a problem using wildcards and the column names display just fine.
For clarity:
this works : SELECT * FROM WUNITS.DVIRS
this works : SELECT ID___00001 FROM WUNITS.DVIRS
This doesn't : SELECT Id FROM WUNITS.DVIRS
This does work for older tables created the same way : SELECT Id FROM WUNITS.DVIRS
Here is a screenshot of the column definitions
What am I doing wrong?
Since you mention system name, I'll assume you're using Db2 for IBM i....
I suspect you've created the table with quoted column names...you wouldn't see mixed case column names otherwise, they would be all CAPITALS.
For example:
create table dtcwilt.dvirs (
"Id" bigint
, "AssetNumber" varchar(25)
, WoNumber bigint
, WoStatusId int
)
Not sure what tool you're using to display the columns, but the ACS schema tool would show the quoted name.
The quotes are actually part of the name, you'd need to use the quoted name, with proper capitalization, in your select:
This should work:
SELECT "Id" FROM WUNITS.DVIRS
This would not:
SELECT "ID" FROM WUNITS.DVIRS
Related
DBeaver adds a character (the first letter of the table name) when auto completing table names, resulting in a query that looks like this:
select * from countries c;
As far as i can tell, it works, and has no impact on the query/results... can anyone enlighten me as to what it (the c) is?
"C" is an alias name of the "countries" table. Here is the reference: https://www.techonthenet.com/mariadb/alias.php
Looks like we've loaded some snowflake tables via ELT with "TO, FROM" as column names and they are both classic functions in any sql tool
Whenever I run a query for specifically those columns, there's always an error - how do I fix it apart from changing column names? Don't want to change column names as ELT process always happens from mongoDB via log based replication (stitch data)
select * - works perfectly , all other columns work too. Just "to" , "from" is the issue - should that never be used a columns?
select to, from from table limit 10 ; // tested [to, "to", 'to'] - none work
Error: SQL compilation error: error line 1 at position 7 invalid identifier '"to"'
Any ideas how to fix this apart from source column change or snowflake column changes?
Snowflake uses the standard double quotes to escape identifiers. However, when identifiers are escaped, the case of the letters matters, So, these are not the same:
select "to"
select "To"
select "TO"
You need to choose the one that is correct for your column names.
In addition spaces matter, so these are not the same:
select "to "
select " to"
select "to"
That is, what looks like to might be something else. You need to know what that is to escape the name properly.
If you can't figure them out, there is a trick to create a view to give the table reasonable names. Something like this:
create view v_t (to_date, from_date, . . .) as
select *
from t;
You need to be sure to include all the column names in the table in the column name list, in the same order as they are in the table. Then you can use the view with reasonable names.
In my PostgreSQL database I have table that is inside import schema. When I want to get all data from the column I do:
select * from import.master_plan
This query works fine. But when I try to for example get only title column values:
select import.master_plan.title from import.master_plan;
it returns:
ERROR: column master_plan.title does not exist
LINE 1: select import.master_plan.title from import.master_plan;
^
HINT: Perhaps you meant to reference the column "master_plan. title".
I've also tried:
select title from import.master_plan;
but this also not works. I'm using PostgreSQL 10. How can I fix that?
I would suggest that you use a table alias instead:
select mp.title
from import.master_plan mp;
This is much easier to read and to type.
Judging from the error message, though, the name seems to have leading spaces. Something like:
select mp." title"
from import.master_plan mp;
might work. If this is the case, alter the table and rename the column.
I'm developing a tool which imports data into on-the-fly generated schema. Therefore I have little control over what the table or column names will look like. I recently run into an issue with creating 2 columns in the table which have identical name but different case. The problem could be demonstrated on this simplest DDL operation:
CREATE TABLE "a" (
"c1" integer,
"C1" integer
)
This fails for me in the program as well as h2 console with:
Duplicate column name "C1"; SQL statement: create table "a" ( "c1"
integer, "C1" integer )
This is working fine in PostgreSQL for example and I think it should work as the SQL specification requires case sensitivity when values are double-quoted.
I'm currently using in-memory h2 database.
EDIT: It runs out the reason was the connection was established with option DATABASE_TO_UPPER=false which caused this behaviour
In H2 Names are not case sensitive.
H2 docs
...but...
Quoted names are case sensitive, and can contain spaces.
H2 docs of Quoted Names
I just ran this exact example in a local instance of H2 and it worked fine.
create table p ("c1" integer, "C1" integer);
insert into p values (1,2);
select * from p;
I think your SQL is being changed before it runs in H2. Everything may be being capitalized before the SQL is run.
Per your update the connection was established with option DATABASE_TO_UPPER=false which caused this behaviour
I found problem when trying to retrieve specific name column that using syntax/statement/command using sql.
Example I have table 'dcparam' with name some column 'SELECT', 'INSERT', 'UPDATE' in database sqlserver.
Then I trying to select using query:
SELECT SELECT,INSERT,UPDATE FROM dcparam
Well it could be solve using "*" in select, but then how if i wish only specific column.
Regard.
Add square brackets around the column name.
SELECT [SELECT], [INSERT], [UPDATE] FROM dcparam
It's probably best to reconsider your column names in the long run however...