How do I find out what text was used to create a view in oracle sql, especially how do I find out what columns may be hidden?
select view_name, text from all_views where viewname = 'XYZ';
will give me the first few words only
sql developer has a tab for this, I'm just wondering if there is a way to do it from the command line in sqlplus.
By default SQL*Plus only shows the first 80 characters of long and clob columns. You can do set long 32767 (or some other large number; 30000 seems to be common, I think from older releases where the limit was 32K and that was easier to type, but it is 2M now) and reissue your query.
You can also use the dbms_metadata package to get the view DDL, if it is your view (in your schema) or you have the select catalog role.
select dbms_metadata.get_ddl('VIEW', 'XYZ')
You'll need to do set long for that to show you a useful amount of output too; and specify the schema with the third argument if it isn't in your schema.
Related
I'm new to oracle (or SQL in general) and trying to get stuff done.
In MS SQL Server I can do select * from tablename; and it displays all the data in a tabulated format. If I do that in Oracle it displays the data in a weird format that's hard to read, unless I specifically select the columns I want.
Is there a way to display the data in Oracle formatted like regular MSSQL format?
I looked around and people say to use SHOW COLUMNS FROM TABLENAME; but that gives me an error saying "unknown option". I can do Desc tablename but that only gives me the metadata.
Welcome to Oracle!
As a new user, we have 2 command-line interfaces. It sounds like you're using SQL*Plus. We also have something called SQLcl.
The latter includes automatic output formatting so you don't have to do the things like 'linesize' or 'format' in your commands to get readable query results.
I think you are using SQLPlus window to see output. You have to format it to see good.
First
set linesize 5000;
This command will make your row long enough to hold columns. You need to increase or decrease number according your need.
Set pagesize 100;
Here, 100 is number of records in one page to show.
Moreover, some column length are very big in database. You need to format display for those specific column to show it as short.
COLUMN Column_NAME FORMAT A10;
Here, a10 is ten digit for that column.
Use below query, use solution 2 if you don't know exact table name:
--Solution1
select column_name,table_name from all_tab_cols where table_name='table_name'
--Solution2
select column_name,table_name from all_tab_cols where table_name like '%table_name%'
Download SQLDeveloper from Oracle. It's free to use.
I do not have sufficient privileges to use a CREATE statement, I can only SELECT. I have a script that has three distinct parts and calculations that need to run and each one references the same complicated WITH statement selection that redundantly clutters the code and is a pain to maintain in three separate locations.
I have tried creating temp tables and views, but again, privileges do not support. Is there a way using either SQL or PL/SQL syntax to define my WITH statement ONCE without using CREATE, and then reference it like I would any other table? Example:
--Define the temp table
WITH tempview AS (SELECT .... FROM ...);
--First query
SELECT ... FROM tempview;
/
--Second query
SELECT ... FROM tempview;
/
--Third query
SELECT ... FROM tempview;
/
Getting the correct permissions and creating permanent objects is the best approach. It sounds like this view would only be used in a single script, which doesn't necessarily make it any less valid to create it, but you might find it harder to justify depending on your DBA and policies. It's certainly worth trying that approach, as #DCookie suggested.
If that fails then there may be hacky workarounds, depending on the client you will run this script in.
For instance, in SQL*Plus it's possible to abuse substitution variables to get something close to what you describe. This uses the define command to create a substitution variable that contains the 'view' query, and then uses that variable inside a WITH clause. (You can't replace the entire with like this, but it's maybe clearer like this anyway). I'm used a trivial dummy query:
define tempview_query = 'SELECT * -
FROM dual -
UNION ALL -
SELECT * -
FROM dual'
WITH tempview AS (&tempview_query)
SELECT * FROM tempview;
WITH tempview AS (&tempview_query)
SELECT * FROM tempview;
When the script is run the output produced is:
D
-
X
X
2 rows selected.
D
-
X
X
2 rows selected.
I've also executed set verify off to hide the substitutions, but turning it on might be instructive to see what's happening.
Notice the dashes at the end of each line of the query; that's the continuation character, and as the define docs mention:
If the value of a defined variable extends over multiple lines (using the SQL*Plus command continuation character), SQL*Plus replaces each continuation character and carriage return with a space.
so the 'new' query shown by set verify on will have your entire view query on a single line (if you display it). It's feasible that with a long enough query you'd hit some line length limit but hopefully you won't reach that point (except you did; see below).
You can do the same thing in SQL Developer, but there the continuation needs to use two dashes, so:
define tempview_query = 'SELECT * --
FROM dual --
UNION ALL --
SELECT * --
FROM dual'
except it isn't quite the same as the continuation in SQL*Plus; here the define has to end with a dash, but it is not replaced in the way the SQL*Plus docs describe - so with a single dash the define works but the query ends up invalid. (At least in 4.2.0; possibly a bug...) By using two dashes the multi-line define still works, the dashes remain part of the query, but they're treated as comment markers; so they make the substituted query look odd (again, if you display it) but don't stop it working. You won't notice with set verify off unless someone looks in v$sql.
If your query exceeds 240 characters - which is rather likely unless it's trivial enough to repeat anyway - you'll hit something like:
string beginning "'SELECT * ..." is too long. maximum size is 240 characters.
Both SQL*Plus and SQL Developer allow you to set a substitution variable from a query, using the column ... new_value command:
column tempalias new_value tempview_query
set termout off
select q'[SELECT *
FROM dual
UNION ALL
SELECT *
FROM dual]'
FROM dual;
set termout on
The query selects the text of your view query as a string; I've used the alternative quoting mechanism, with [] as the delimiters, so you don't have to escape any single quotes in the view query. (You need to pick a delimiter that can't appear in the query too, of course). Also note that you don't need the line continuation character any more.
The text literal that query generates is aliased as tempalias. The column command sets the tempview_query substitution variable to whatever that aliased column expression contains. Using the substitution variable is then the same as in the previous examples.
WITH tempview AS (&tempview_query)
SELECT * FROM tempview;
The set termout lines just hide that generating query; you can temporarily omit the off line to see what the query produces, and that it does exactly match the view query you expected.
Other clients might have similar mechanisms, but those are the only two I'm really familiar with. I should probably also reiterate that this is a bit of a hack, and not something I'd necessarily recommend...
Another trick with SQL*Plus is to import code from a second SQL script. You can do this with the # command (making sure to put the # at the very start of a line), e.g.:
tempview.sql
WITH tempview AS (SELECT .... FROM ...)
(notice there is no ending semicolon ; here, and make sure you either don't have a blank line at the end of the file or set sqlblanklines on)
main.sql
--First query
#tempview.sql
SELECT ... FROM tempview
/
--Second query
#tempview.sql
SELECT ... FROM tempview
/
--Third query
#tempview.sql
SELECT ... FROM tempview
/
I have a SqlServer db that I would like to port to MySQL. What's the best way to to this. Things that need to be ported are:
Tables (and data)
FileStream → MySQL equivalent?
Stored Procedures
Functions
Data types are relatively similar.
There is no equivalent to FileStream in MySQL - the files must either be stored as BLOBs, or on the file system while the path is stored in the database.
Migrating away from TSQL means:
There's no WITH clause in MySQL - it will have to converted into a derived table/inline view
There's no TOP syntax - these have to be converted to use LIMIT
There's no ranking/analytic functionality in MySQL - can't use ROW_NUMBER, RANK, DENSE_RANK or NTILE. See this article for alternatives.
MySQL views have notoriously limited functionality:
The SELECT statement cannot contain a subquery in the FROM clause.
The SELECT statement cannot refer to system or user variables.
Within a stored program, the definition cannot refer to program parameters or local variables.
The SELECT statement cannot refer to prepared statement parameters.
Any table or view referred to in the definition must exist. However, after a view has been created, it is possible to drop a table or view that the definition refers to. In this case, use of the view results in an error. To check a view definition for problems of this kind, use the CHECK TABLE statement.
The definition cannot refer to a TEMPORARY table, and you cannot create a TEMPORARY view.
Any tables named in the view definition must exist at definition time.
You cannot associate a trigger with a view.
As of MySQL 5.0.52, aliases for column names in the SELECT statement are checked against the maximum column length of 64 characters (not the maximum alias length of 256 characters).
Dynamic SQL will have to be converted to use MySQL's Prepared Statement syntax
A guide/article with some useful tips is available on the official MySQL dev site.
This is not for the faint of heart. Here is an article that explains what you are in for:
http://searchenterpriselinux.techtarget.com/news/column/0,294698,sid39_gci1187176,00.html
In PL/SQL Developer v7.1.x, is there way way to ignore large data types in queries or the "Query Data" feature. For example: If you right click on table FOO, and select "Query Data" this will execute a SELECT * FROM FOO. If that table contains BLOB data the query will take a while to complete and temporarily lock up the application. This is especially problematic when querying remote databases (for obvious reasons).
I would like a way to tell PL/SQL Developer not to retrieve large data by default. I know there is a way to limit the ResultSet size but this doesn't do what I am looking for.
I could just select each column I wanted ignoring certain ones but then I couldn't use the "Query Data" feature.
Thanks.
No, the Query Data feature does one thing and one thing only - queries all the data.
What you might find useful is that you can drag the name of a table or view from the Browser into a SQL Window, choose "Select" from the menu that pops up, and it will generate a SELECT statement on the table with all the column names included - but does not execute the query straight away. You can then edit it however you like (e.g. comment out the LOB columns) before you run it.
I know that Toad has something like that built in, but I'm not aware of a PL/SQL Developer option that disables BLOBS.
The option you are left with, for now, is to simply select all the columns individually and truncate the blob.
ie:
select foo, bar, trunc(baz,100) from foo where ...
Create a View that doesn't contain the blob column or whatever columns you don't routinely want to look at.
I need to write some sql that will allow me to query all objects in our Oracle database. Unfortunately the tools we are allowed to use don't have this built in.
Basically, I need to search all tables, procedures, triggers, views, everything.
I know how to search for object names. But I need to search for the contents of the object.
i.e. SELECT * FROM DBA_OBJECTS WHERE object_name = '%search string%';
Thanks,
Glenn
I'm not sure I quite understand the question but if you want to search objects on the database for a particular search string try:
SELECT owner, name, type, line, text
FROM dba_source
WHERE instr(UPPER(text), UPPER(:srch_str)) > 0;
From there if you need any more info you can just look up the object / line number.
For views you can use:
SELECT *
FROM dba_views
WHERE instr(UPPER(text_vc), UPPER(:srch_str)) > 0
i'm not sure if i understand you, but to query the source code of your triggers, procedures, package and functions you can try with the "user_source" table.
select * from user_source
I would use DBA_SOURCE (if you have access to it) because if the object you require is not owned by the schema under which you are logged in you will not see it.
If you need to know the functions and Procs inside the packages try something like this:
select * from all_source
where type = 'PACKAGE'
and (upper(text) like '%FUNCTION%' or upper(text) like '%PROCEDURE%')
and owner != 'SYS';
The last line prevents all the sys stuff (DBMS_ et al) from being returned. This will work in user_source if you just want your own schema stuff.
i reached this question while trying to find all procedures which use a certain table
Oracle SQL Developer offers this capability, as pointed out in this article : https://www.thatjeffsmith.com/archive/2012/09/search-and-browse-database-objects-with-oracle-sql-developer/
From the View menu, choose Find DB Object. Choose a DB connection. Enter the name of the table. At Object Types, keep only functions, procedures and packages. At Code section, check All source lines.
ALL_SOURCE describes the text source of the stored objects accessible to the current user.
Here is one of the solution
select * from ALL_SOURCE where text like '%some string%';
In Oracle 11g, if you want to search any text in whole database or procedure below mentioned query can be used:
select * from user_source WHERE UPPER(text) LIKE '%YOUR SAGE%'