In the following piece of code, what is the purpose of the square?
SELECT Value, [Default] AS Selected FROM SKUOptVal WHERE SKUOptID = ?
Cheers.
This code is written for SQLite3.
It's an identifier. It's the same as saying "Default". It's included for compatibility with MS Access. Since Default is a keyword in SQL, it needs to be quoted if used as an identifier, as it is here.
The column is named default, which is the same as an SQL keyword. Thus, the brackets are used to denote we are referring to the column default and not the keyword default.
Related
I have a table created successfully.
1 of the column name is code and another 1 is "deleted".
Thus, I plan to use this 2 field to create its index. I am doing something like follow:
CREATE INDEX SADM.IDX_SC_IDX1 on SADM.SC ("code" ASC, "DELETED") ALLOW REVERSE SCANS;
This is working fine in my local. However, I hit this error in UAT:
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0205N Column, attribute, or period "code" is not defined in
"SADM.SC". SQLSTATE=42703
I double check the table and confirm the "code" column or "deleted" is exist and same with my local.
I believe something wrong is inside but I cant find the root cause.
Kindly advise.
As per my comment. You are using double-quotes around the column names the column case (uppercase, lowercase) must match between the table-definition and the index definition.
Make sure to name the columns as they were created and are listed in the system catalog. Look for the column names in SYSCAT.COLUMNS (for most Db2 versions). If you don't use quotes, Db2 converts identifiers to uppercase by default. However, if you use quotes they always need to be referenced exactly as written.
"code" is different from "Code" or "COde" or CODE. Thus, check how the column is really named.
I've found many discussions about INSERT OR REPLACE and I thought it was clear to me, but after reading this article saying:
The following illustrates the syntax of the REPLACE statement.
INSERT OR REPLACE INTO table(column_list)
VALUES(value_list);
Or in a
shorter form:
REPLACE INTO table(column_list)
VALUES(value_list);
I'm afraid I missed something.
Why is the INSERT statement needed together with REPLACE?
Does it actually make any difference in examples like this one, for instance?
When in doubt, consult the documentation (emphasis mine):
The REPLACE command is an alias for the "INSERT OR REPLACE" variant of the INSERT command. This alias is provided for compatibility other SQL database engines. See the INSERT command documentation for additional information.
Using Oracle 11gR2
You can't create a username starting with a number:
SQL> create user 123 identified by temp;
create user 123 identified by temp
*
ERROR at line 1:
ORA-01935: missing user or role name
However, you can create it as:
SQL> create user "123" identified by temp;
User created.
Somebody knows possible problems with this kind of users?
Somebody knows oracle rules/reasons why you can't create it without quotes, ie, to have usernames starting with numbers?
Thanks in advance
Problems with quoted identifiers
Quoted identifiers can be successfully used for almost any Oracle object, including users. In theory, they work everywhere. In practice, you will run into many inconveniences and problems with quoted identifiers.
From the SQL Language Reference:
"Note: Oracle does not recommend using quoted identifiers for database object names. These quoted identifiers are accepted by SQL*Plus, but they may not be valid when using other tools that manage database objects."
Once you use double quotes, every reference to that object must use double quotes, and the correct case. You'll find lots of problems with tools that don't always use double quotes. And problems with scripts that look at metadata and don't always add double quotes. Quoted identifiers are just asking for trouble.
Why does Oracle have quoted identifiers?
This question is harder to answer, but I would guess limiting the types of characters used by objects makes parsing much easier. SQL already has a lot of keywords, and has many weird language ambiguities. If object names started with numbers it would make it difficult to differentiate between real numbers and objects.
For example, without quoted identifiers, this simple statement could be a mess:
select 1.1 + 2.2 from some_table;
Without restricting object names, 1.1 could be a huge number of things, and the parser would have to look for objects named "1", and then dependent objects named "1", and then determine if that takes precedence over the number "1.1".
Weird names are possible in languages, but I assume when someone wrote the first SQL compiler 40 years ago they decided not to make their lives so complicated just to accommodate a few weird names.
Check if the user name is not present in reserved words and doesn't start with number:
SELECT *
FROM v$reserved_words
ORDER BY keyword
If you are creating user try this:
alter session set "_ORACLE_SCRIPT"=true;
CREATE USER oe IDENTIFIED BY oe;
check your connection type is cdb or not. if it is cdb as shown in the below
image
use prefix c## before the username in the command for creating user
I'm using the following command to update a field in my database:
UPDATE Movies SET 'From'=2 WHERE 'Name'="foo";
I'm using sqlite3.exe in windows (command prompt). Although no error message is produced, nothing changes in the table. I examined the database with a couple of gui tools and I'm sure UPDATE does nothing.
'From' is of type integer and 'Name' is text.
The problem you've got is that you're getting your quoting wrong. SQLite follows the SQL standard here, and that specifies what quote characters to use: '…' is for strings, and "…" is for tokens (like special names used as column or table names). Sometimes it manages to guess what you mean anyway and compensate for getting it wrong, but it can't with the WHERE clause because that is syntactically correct (if decidedly unhelpful):
Swapping the quoting appears to work:
UPDATE Movies SET "From"=2 WHERE "Name"='foo';
Those aren't good column names. Both are keywords, best avoided, and not self-explanatory at all.
Do a SELECT to see how many rows match the WHERE clause in the UPDATE. If none come back, you have your answer.
Did you commit the UPDATE? Is auto commit turned on?
I'm using SQL Developer to create oracle tables. I'm trying to create the columns without quotes, but after creating the table, when I see the DDL, all columns and table names are in quotations. I want all the columns to be case-insensitive.
How do I do that? Please advise.
The context here is, I have my code in PHP. I'm migrating my backend from MySQL to Oracle. While using MySQL, I referenced all my table columns in lower case. But it looks like OCI_FETCH_ARRAY returns the data in Uppercase columns.
So do I have to change my PHP code to use Uppercase or is there any other alternative? I have hell lot of code to change!!
Ahh, finally figured this out. Yes I agree, quotations dont always make an object case-sensitive, but my problem was OCI_FETCH_ALL, OCI_FETCH_ARRAY etc retrieved the table columns in Upper case, whereas I wanted them in lower case. The following statement is a workaround for the issue. it converts the columns into lower case.
$data_upper = oci_fetch_assoc($data_res);
$data = array_change_key_case($data_upper, CASE_LOWER);
Thanks!!
Quotation marks don't always make an object case-sensitive. Objects in all upper-case are always case-insensitive, even if they are surrounded by quotation marks.
SQL> create table test1("QUOTES_DONT_DO_ANYTHING_HERE" number);
Table created.
SQL> select quotes_DONT_do_ANYTHING_here from test1;
no rows selected
You normally only see quotation marks because some tools automatically add them to everything.