Is there a column comment syntax that allows me to specify a column comment directly where I declare the column in the create table statement (i.e. inline)? The 11g spec does not mention anything, on another page something is mentioned but I could not get it to work. There is a way to specify comments after creating the table, but I think it is annoying that the comment is separated from the field definition. I am looking for something like this (which does not work):
create table whatever (
field number(15,0) primary key comment 'primary key generated from sequence pkseq',
...
)
I'm afraid the "annoying" COMMENT ON syntax is the only way of doing this. SQL Server, PostgreSQL and DB2 use the same syntax (even though, as far as I know, there is no ANSI standard syntax for adding comments to database objects).
MySQL supports the way you would like it to work. I agree it would be a nicer mechanism, but in my experience so few people use comments at all that I doubt Oracle will ever change it.
I'm afraid it can only be done after table creation, using the comment on column ... is '' syntax.
A workaround to this annoying syntax is also to view and edit the tables in Oracles SQLExplorer. It contains a wizard that allows you to edit the comments right next to the columns. It even allows easy creation of alter table scripts.
My procedure when editing tables is to enter the changes in the wizard without actually executing them, then go to its DDL tab and retrieve the SQL from there (as update, not full create script) and press cancel on the wizard. Then I put the created SQL into the SQL script I am writing. Only when I am finished with the script I execute everything; I do never make any changes with the wizard itself.
Test on sqlplus (or similar), but the syntax is as follows:
-- assuming you have privileges
COMMENT ON COLUMN SCHEMA1.TABLE1.COL1
IS 'My comment'
-- then you can double check like this
SELECT * FROM all_col_comments WHERE
(OWNER, TABLE_NAME, COLUMN_NAME)
IN (('SCHEMA1','TABLE1','COL1'));
Note that the comment will now show in SQLDeveloper (or Toad or whatever env you have) until you reopen said table's properties.
Similar syntax can be used to annotate tables, indexes and materialized views. [source: https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_4009.htm]
I understand similar syntax exists for MySQL and others, but it is not proper ANSI. It's very useful, though.
Related
EDIT: This question was based on the incorrect premise that SQL VIEWS were cleared from a database when the user that created them disconnects from the server. Leaving this question in existence in case others have that assumption.
I'm trying to use views in my database, but I'm running up against an inability to save the code as a SQL Server object for repeated use.
I tried saving CREATE VIEW statements as procedures and user defined functions, but as many have answered on stack overflow, CREATE PROCEDURE and CREATE FUNCTION are incompatible with CREATE VIEW due to the only one in batch issue.
Obviously I don't want to retype my CREATE VIEW statements every time, and I'd prefer not to have to load them from text files. I must be missing something here.
You don't really "save" CREATE/ALTER statements. The create or alter statement changes the structure of the database. You can use SSMS to generate the statement again later by right clicking on the view, and choosing Script as->Create. This inspects the structure of the database and generates the statement.
The problem with this approach is your database now consists of both a structure definition(DDL) as well as its contents, the data. If you dropped/created the database to clear its data, you'd also have lost the structure. So you always need a database hanging around for the structure and back it up to ensure you don't ever lose the DDL.
Personally I would use Database Projects as part of Visual Studio and SQL Server Data Tools. This allows you to keep each View, Table, etc. as separate files, and then update the database using schema compare. The main benefit being you can separate the definition of the database from the database itself, and also source control or backup the DDL files.
If you really want to, you could create a view in a proc like this:
CREATE PROCEDURE uspCreateView AS
EXEC('CREATE VIEW... ')
Though, you'll have to escape single quotes in your view code with ''
However, I have to agree with the other comments that this seems like a strange thing to do.
Some other thoughts:
You can use sp_helptext to get the code of an existing view:
sp_helptext '<your view name here>'
Also, INFORMATION_SCHEMA.VIEWS includes a VIEW_DEFINITION column with the same code:
SELECT * FROM INFORMATION_SCHEMA.VIEWS
I want to delete a table from the database, which I know is not being used anywhere in our Java code-base. I was able to also delete it from our DB, but I'm not sure that this may not still pose some kind of problem. Maybe it can still be referenced from a Stored Procedure, or something of the like?
Or does the database actually guarantee that under any circumstance this will not be the case when deleting a table? In case it may be a problem, what would be the best way to search for this specific string in the db such as to find its possible usages?
Unfortunately I don't have dba access to this db.
Thanks
no such guarantee
but you can run this to find any reference to the table in a stored procedure, package or function
select * from dba_source where lower(text) like '%<tablename>%'
I think there are 2 reference of table you need to care about.
Dependencies (in table browser, sql navigator/toad has, not sure about others)
Dynamic sql call that table in procedure/function/package. Refer here
But those're not all, because some dynamic sql may use string concatenate
execute immediate 'select max(name) from customer_' || provinceCode into testName;
I want a script that inserts table comments and column comments. Said script must be unique and run satisfactorily both on Oracle and MySQL. Furthermore, I prefer it to be written in Standard SQL.
This is how I do it now. But it does not work on MySQL.
comment on table F_Transaction
is 'Fact table for system transactions';
comment on column F_Transaction.Transaction_Date
is 'Date in which the transaction took place';
What SQL construction should I use to achieve my purpose?
The standards do not seem to define any way to define table or column comments (looks like they don't even mention them). So, the syntax for comments on tables/columns can vary from one DBMS to another.
It seems that a number of DBMS agree with Oracle's COMMENT ON syntax (see Oracle create table with column comments).
With MySQL it's necessary to specify the comments along with the table/column definition (in CREATE TABLE or ALTER TABLE sentences). See this related question: Alter MYSQL Table To Add Comments on Columns.
I am trying to dynamically create a SQL table only if it's not already existing. I have seen many solutions on the internet but they usually rely on a specific database, while I'm trying to find the most generic solution.
I was thinking of always running the CREATE command and then assuming that if it fails then the table exist and I can start inserting data into it. I can't see any flaw in this reasoning (not counting performance issues), but I might be wrong.
Is this an acceptable method?
Can you suggest other methods which are database independent, or that use ANSI SQL that all RDBMS would accept?
if there is a table - say - EMP, does that really imply that it is the same EMP that you are expecting?
Either query the appropriate data dictionary for the table structure, or fill your code with a ton of error checking and conditional logic...
INFORMATION_SCHEMA is part of the ANSI SQL Standard, so you should be able to:
IF NOT EXISTS(SELECT NULL FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'YourTable')
CREATE TABLE...
what about: create table if not exists
I'm new to SQL. We have some code that should work on SQL Server 2005/2008, Oracle 10 as well as Sybase.
I was writing a script to try to figure out which tables a given stored procedure modifies (but does not drop), e.g insert, update and delete.
The delete one turned out being puzzling - sometimes I see statements like:
delete phone_book where ...
as opposed to:
delete from phone_book where ...
So ... is the from keyword truly optional in this case? Does this cause any problems? Is it just a bad style, or does it not matter?
I have not found a reference to T-SQL that would make from optional. I suppose that this is what would unify all 3 vendors I mentioned above.
Questions/comments/links are welcomed (or is it welcome?).
At this place the FROM is optional (SQL Server, Oracle, Sybase).
However, there are subtle differences: Oracle for instance allows assigning an alias to the table name, where SQL Server doesn't; and other things are also a little bit different.
Also note that your FROM sample is differnet from the following where it is mandatory:
DELETE phone_book FROM some_table WHERE ...
Short Answer: Luceros answer is correct: it is optional
I have to maintain sql and adapt it between sql-server and Oracle. Here are some rules:
Write Scripts manually, don't use generated code.
Always use INSERT INTO.
Always DELETE -- without FROM.
Do not use " - quoted identifier.
Remove all [ ] and dbo. (Schema names)
Attention when you see DELETE ... FROM ...
Attention when you see UPDATE ... FROM ...
ORACLE Select statements need a from clause you can use from DUAL
OK you can script your objects and edit them in a standard way
USE [Current_DB] -- you don't want a reference to your test database go into production script
SET ANSI_NULLS ON -- decide once which settings to use -- don't switch on and off
SET QUOTED_IDENTIFIER ON -- quoted identifiers are case-sensitive.
INSERT INTO is required by Oracle.
That is my personal style don't use optional keyword, learn the defaults
You have to quote an identifier, if you use one of ORACLES reserved keywords as column name, we entered that pitfall and in the long run it would have been better to rename the column on the sql-Server side.
Oracle doesn't use these.
Oracle doesn't support this syntax.
Oracle doesn't support this syntax.
From the Microsoft SQL Server documentation, FROM is optional.
from is optional in delete from in those three DBMSes but it is mandatory according to the SQL standard. I would always use delete from to ease the migration of SQL code from one DBMS to another.
In SQL Server, FROM of DELETE FROM is optional and DELETE without FROM is not SQL standard while DELETE FROM is SQL standard.
I experimented DELETE FROM and DELETE without FROM on SQL Server, MySQL, PostgreSQL and SQLite as shown below:
Database
DELETE FROM
DELETE
SQL Server
Possible
Possible
MySQL
Possible
Impossible
PostgreSQL
Possible
Impossible
SQLite
Possible
Impossible
In addition, I also experimented INSERT INTO and INSERT without INTO on SQL Server, MySQL, PostgreSQL and SQLite as shown below.
Database
INSERT INTO
INSERT
SQL Server
Possible
Possible
MySQL
Possible
Possible
PostgreSQL
Possible
Impossible
SQLite
Possible
Impossible