I am using DevArt's dotConnect and Entity Developer for my application. I've created the tables using the Entity-First feature.
I notice that many of the column types are set to CLOB. I only have experience with MySQL and Microsoft SQL server, so I am not sure about using CLOB for the application. I did some reading, and found out that CLOB are for large chunk of data.
The questions are:
Is using CLOB for most fields, such as the user's gender (which should be a varchar (1) ) or the full name, feasible? The steps for converting a CLOB field to VARCHAR2 requires dropping the column then re-creating it, and is buggy in DevArt's Entity Explorer, so I would like avoid it if possible. Edit: I just found out that if you set a maximum length for a string field it'll automatically be a VARCHAR2.
Are there any equivalents for TINYTEXT in Oracle?
It is a very bad idea to use a CLOB datatype for a column which ought to be VARCHAR2(1). Apart from the overheads (which are actually minimal, as Oracle will treat inline CLOBs of < 4000 characters as VARCHAR2) we should always strive to use the most accurate representation of our data in the schema: it's just good practice.
This really seems like a problem with the DevArt tool, or perhaps your understanding of how to use it (no offence). There ought to be some way for you to specify the datatype of an entity's attribute and/or a way of mapping those specifications to Oracle's physical datatypes. I apologise if this seems a little vague, I'm not familar with the product.
So, this is the basic problem:
SQL> desc t69
Name Null? Type
----------------------------------------- -------- --------
COL1 CLOB
SQL>
SQL> alter table t69 modify col1 varchar2(1)
2 /
alter table t69 modify col1 varchar2(1)
*
ERROR at line 1:
ORA-22859: invalid modification of columns
SQL>
We can fix it by using DDL to alter the table structure. Because the schema has many such columns it is worthwhile automating the process. This function drops the existing column and recreates it as a VARCHAR2. It offers the option to migrate data in the CLOB column to the VARCHAR2 column; you probably don't need this, but it's there for completeness. (This is not production quality code - it needs error handling, managing NOT NULL constraints, etc)
create or replace procedure clob2vc
( ptab in user_tables.table_name%type
, pcol in user_tab_columns.column_name%type
, pcol_size in number
, migrate_data in boolean := true )
is
begin
if migrate_data
then
execute immediate 'alter table '||ptab
||' add tmp_col varchar2('|| pcol_size|| ')';
execute immediate
'update '||ptab
||' set tmp_col = substr('||pcol||',1,'||pcol_size||')';
end if;
execute immediate 'alter table '||ptab
||' drop column '|| pcol;
if migrate_data
then
execute immediate 'alter table '||ptab
||' rename column tmp_col to '|| pcol;
else
execute immediate 'alter table '||ptab
||' add '||pcol||' varchar2('|| pcol_size|| ')';
end if;
end;
/
So, let's change that column...
SQL> exec clob2vc ('T69', 'COL1', 1)
PL/SQL procedure successfully completed.
SQL> desc t69
Name Null? Type
----------------------------------------- -------- ---------------
COL1 VARCHAR2(1)
SQL>
Calling this procedure can be automated or scripted in the usual ways.
Using a CLOB for something like a Gender column would, at a minimum, be extremely unusual. If the DDL this tool generates specifies that the LOB data should be stored inline rather than out of line, I wouldn't expect to be any horrible performance issues. But you probably will create problems for other tools accessing the database that don't handle LOBs particularly well.
There is no equivalent in Oracle to Tinytext in MySQL. A CLOB is a CLOB.
A simpler solution is to go to Model Explorer -> Model.Store -> Tables/Views, find the necessary column and change the type of this field to VARCHAR2.
Then run the Update Database from Model wizard to persist the changes to the database.
Don't forget to set the MaxLength facet (however, the problem with it is already fixed in the upcoming Beta build).
Related
It is possible to build a statement using variables for the table name without creating a VARCHAR and using EXECUTE IMMEDIATE?
ex:
#table_name := test_table
UPDATE #table_name
SET col1 = val1
WHERE condition...;
this is my actual workaround:
DECLARE
sql_stmt VARCHAR2(1000);
table_name VARCHAR2(30) := 'test_table';
BEGIN
sql_stmt := 'UPDATE ' || table_name || ' SET col1 = val1...';
EXECUTE IMMEDIATE sql_stmt;
END;
/
"[Is it] possible to build a statement using variables for the table
name without creating a VARCHAR and using EXECUTE IMMEDIATE?"
No.
SQL is a strongly typed language. The compiler requires the actual table name in order to validate the various components of the SQL statement ( projection, filters, etc).
Dynamic SQL (EXECUTE IMMEDIATE and DBMS_SQL) is necessary to short-circuit the compile time validation. Essentially it's a mechanism relieving the compiler of the burden of verifying the SQL and taking it on ourselves (because humans are so much better at such jobs than machines. Not).
Alternatively, it's a mechanism for generating runtime errors instead of compilation errors.
Either way, it's pretty odd to know the name of the COLUMN in the filter but not the name of the TABLE being updated.
Can I execute a select query stored as a Varchar in another table's column ??.
Suppose there is a table TB_SQL_QUERIES, with column name as SQL_QUERY_TEXT and ID.
Is there a way to execute a query from this table where ID=(to be input by the user)
Yes, you would do something like:
DECLARE
l_sql VARCHAR2(4000);
BEGIN
SELECT sql_query_text INTO l_sql
FROM tb_sql_queries
WHERE id = 1;
EXECUTE IMMEDIATE l_sql;
END;
See EXECUTE IMMEDIATE.
Inprovising on the other answer about EXECUTE IMMEDIATE :
Firstly, in 12c, you can have 32767 for SQL rather than the limitation of 4000 in prior versions. Thus, you can eliminate the effort to have multiple variables to keep concatenating the dynamic string whenever it exceeds 4000 characters.
Secondly, since you mentioned that the input would be by user, you need to have Bind variable to get the value at run time.
I'm about to learn pl/sql and currently I'm not understanding whats going wrong with my code.
What I'm trying to do is to dynamically copy(backup) a specific table.
So easy thing: I already created a backupTable, because I will use that quite often actually.
So the first try was following:
EXECUTE IMMEDIATE 'INSERT INTO '||sSchema_||'.backupTable
SELECT * FROM '||sSchema_||'.table'
This doesnt work as one of the columns contains LONG datatype
Exception ORA-00997: illegal use of LONG datatype
So the next step was trying to pack the thing into a loop and fetch each row individually:
--Initialized as
TYPE cur_typ IS REF CURSOR;
cCursor cur_typ;
rRecord table%rowtype;
--Make sure cursor is closed
IF cCursor%ISOPEN THEN
CLOSE cCursor;
END IF;
--Run the copying
OPEN cCursor FOR 'SELECT * FROM '||sSchema_||'.table';
LOOP
FETCH cCursor INTO rRecord;
EXIT WHEN cCursor%NOTFOUND;
EXECUTE IMMEDIATE 'INSERT INTO '||sSchema_||'.updateTable 'VALUES rRecord';
END LOOP;
CLOSE cCursor;
Which is not being executed due to:
ORA-03001: unimplemented feature
After that I tried to use different other ways to write that loop e.g.
EXECUTE IMMEDIATE 'INSERT INTO '||sSchema_||'.updateTable 'VALUES :1' USING rRecord;
All with the same result: unimplemented feature.
So here comes the question: How do I create a dynamic copy of tables containg LONG datatype? Does anyone has any idea?
Thanks a lot in advance
donny
The target table should be using a LOB (CLOB or BLOB) type.
The LONG RAW datatype is provided for backward compatibility with existing applications. For new applications, use the BLOB and BFILE datatypes for large amounts of binary data.
Oracle also recommends that you convert existing LONG RAW columns to LOB columns. LOB columns are subject to far fewer restrictions than LONG columns. Further, LOB functionality is enhanced in every release, whereas LONG RAW functionality has been static for several releases.
Source: Oracle Database Concepts
CREATE TABLE a_table
(
long_col LONG
);
CREATE TABLE a_backupTable
(
clob_col VARCHAR2(4000)
);
INSERT INTO a_table VALUES ('a');
-- 1 rows inserted.
DECLARE
l_cur SYS_REFCURSOR;
l_long LONG;
BEGIN
OPEN l_cur FOR SELECT long_col FROM a_table;
LOOP
FETCH l_cur INTO l_long;
EXIT WHEN l_cur%NOTFOUND;
INSERT INTO a_backupTable VALUES(l_long);
END LOOP;
CLOSE l_cur;
COMMIT;
END;
-- anonymous block completed
SELECT * FROM a_backupTable;
-- a
In our application, only about 25% of the database triggers show up in DBA_SOURCE. I know I can force the others to show up if I make an actual modification (like adding and removing a space) and then recompile the trigger, but I've got about 400 triggers to modify (it's rather a big application). Just recompiling the triggers with alter trigger <triggername> compile; didn't accomplish anything.
Without the triggers being in DBA_SOURCE, we can't do text searches on the trigger code.
Is there some simpler way to accomplish this? And is there some way to prevent the problem in the future?
We're on Oracle 10.2.0.5.0.
I believe you can find the source in all_triggers. Unfortunately, the data is in a LONG variable (Oracle example of do as I say, not as I do). So, the easiest thing would be to create a scratch table to use, populate it with the data converted to CLOB, and then search:
CREATE TABLE tr (trigger_name VARCHAR2(32), trigger_body CLOB);
INSERT INTO tr
(SELECT trigger_name, TO_LOB(trigger_body)
FROM all_triggers
WHERE owner = 'xxx');
SELECT trigger_name
FROM tr
WHERE trigger_body LIKE '%something%';
I'm not sure why the dba_source view is only sparsely populated for triggers. It's that way on my 10.2.0.4 database as well.
EDIT:
Here is a short script you can use to recreate all your triggers, at which point they should all be in dba_source:
CREATE TABLE temp_sql (sql1 CLOB, sql2 CLOB);
INSERT INTO temp_sql (sql1, sql2) (
SELECT 'CREATE OR REPLACE TRIGGER '||
DESCRIPTION||' '||CASE WHEN when_clause IS NULL THEN NULL ELSE 'WHEN('||when_clause||')' END sql1,
to_lob(trigger_body) sql2
FROM all_triggers
WHERE table_owner = 'theowner');
DECLARE
v_sql VARCHAR2(32760);
BEGIN
FOR R IN (SELECT sql1||' '||sql2 S FROM temp_sql) LOOP
v_sql := R.s;
EXECUTE IMMEDIATE v_sql;
END LOOP;
END;
/
We had the same issue. It's a migration issue from older versions of Oracle.
Triggers were not included in DBA_SOURCE in an earlier version (8?, 9i?) and did not get added to DBA_SOURCE when migrating to newer versions. A recompile did not put them into DBA_SOURCE. But if you drop and recreate the triggers, they will be included in DBA_SOURCE.
So my guess is you have some old triggers and have migrated the database in place to newer versions.
Who owns the triggers?
and, of course, you tried
select owner, object_name
from all_objects
where object_type = 'TRIGGER'
and owner in ('schema1','schema2')
I have a table TABLE_X and it has multiple columns beginning with M_ characters which needs to be dropped. I decided to use the following PLSQL code to drop almost 100 columns beginning with M_ characters. Is it a good employment of dynamic sql and cursors? Can it be better? I didn't know more simple way since ALTER TABLE ... DROP COLUMN doesn't allow subquery to specify multiple column names.
declare
rcur sys_refcursor;
cn user_tab_cols.column_name%type;
begin
open rcur for select column_name from user_tab_cols where table_name='TABLE_X' and column_name LIKE 'M_%';
loop
fetch rcur into cn;
exit when rcur%NOTFOUND;
execute immediate 'alter table TABLE_X drop column '||cn;--works great
execute immediate 'alter table TABLE_X drop column :col'using cn;--error
end loop;
close rcur;
end;
Also. Why is it impossible to use 'using cn'?
This is a reasonable use of dynamic SQL. I would seriously question an underlying data model that has hundreds of columns in a single table that start with the same prefix and all need to be dropped. That implies to me that the data model itself is likely to be highly problematic.
Even using dynamic SQL, you cannot use bind variables for column names, table names, schema names, etc. Oracle needs to know at parse time what objects and columns are involved in a SQL statement. Since bind variables are supplied after the parse phase, however, you cannot specify a bind variable that changes what objects and/or columns a SQL statement is affecting.
The syntax for dropping multiple columns in a single alter statement is this:
SQL> desc t42
Name Null? Type
----------------------------------------- -------- ----------------------
COL1 NUMBER
COL2 DATE
COL3 VARCHAR2(30)
COL4 NUMBER
SQL> alter table t42 drop (col2, col3)
2 /
Table altered.
SQL> desc t42
Name Null? Type
----------------------------------------- -------- ----------------------
COL1 NUMBER
COL4 NUMBER
SQL>
So, if you really need to optimize the operation, you'll need to build up the statement incrementally - or use a string aggregation technique.
However, I would question whether you ought to be running a statement like this often enough to need to optimize it.