I have a requirement to use a sql override query in source qualifier. The override query has an empty port (column) that is supposed to be populated in the database using a store procedure. How do I represent ( create ) the empty port(column) in the source qualifier?
Just create ports that reflect columns returned by the SQL override. Empty column may still have a name.
Related
According to the H2 documentation for CSVREAD
If the column names are specified (a list of column names separated with the fieldSeparator), those are used, otherwise (or if they are set to NULL) the first line of the file is interpreted as the column names.
I'd expect reading the csv file
id,name,label,origin,destination,length
81,foobar,,19,11,27.4
like this
insert into route select * from csvread ('routes.csv',null,'charset=UTF-8')
would work. However, actually a JdbcSQLIntegrityConstraintViolationException is thrown, saying NULL not allowed for column "ORIGIN" and indicating error code 23502.
If I explicitly add the column names to the insert statement like so,
insert into route (id,name,label,origin,destination,length) select * from csvread ('routes.csv',null,'charset=UTF-8')
it works fine. However, I'd prefer not to repeat myself - following the DRY principle :)
Using version 2.1.212.
The CSVREAD function produces a virtual table. Its column names can be specified in parameters or in the CSV file.
INSERT command with a query doesn't map column names from this query with column names of target table, it uses their ordinal positions instead. Value from the first column of the query is inserted into first column specified in insert column list or into first column of target table if insert column list isn't specified, the second is inserted into second column, and so on.
You can omit insert column list only if your table was defined with the same columns in the same order as in the source query (is your case in the CSV file). If your table has columns declared in different order or it has some additional columns, you need to specify this list.
I have flat file data source and Oracle Destination. When I use lookup transformation to validate some data exists in certain tables, it always gives no match. I have converted the data type in derived column, it exactly matches with the table data type. Data type of the column is Unicode string. Exact matches leads to no match output. I am using native SSIS OLEDB connection for Oracle. Please help.
Check your case sensitivity. Sreekanth will not match sreekanth or SREEKANTH
Check for trailing spaces, even in variable length columns.
Those are the two biggest stumbling blocks. If those are not it, then edit your question with the source table definition, the lookup table definition and an appropriate insert statement for both so we can help identify the specifics of what is awry.
I am new to Oracle PL/SQL and have been given some code I am being asked to modify. I have been looking through the oracle documentation and think I know what it is doing but would like to get a verification as to if my understanding is correct or not.
Here is the code:
TYPE array_rec_type IS RECORD (gla_sub tblName.id%type);
v_closes_sc array_rec_type;
TYPE v_sc_type is TABLE OF v_closes_sc%TYPE INDEX BY BINARY_INTEGER;
sc_array v_sc_type;
Here is what I believe is being declared here:
TYPE array_rec_type IS RECORD (gla_sub tblName.id%type);
It looks like a collection is being declared using the column type from the id column from the tblName table. Which could be a number or UUID, etc.
v_closes_sc array_rec_type;
A variable of the newly created type is being created
TYPE v_sc_type is TABLE OF v_closes_sc%TYPE INDEX BY BINARY_INTEGER;
A new type is being created using the collection (Record) previously created a template for the table. The table will have a single column of ID.
sc_array v_sc_type;
A new variable is being created to hold the new table variable.
A record is not a collection, so your explanation is slightly confused. From the docs (which you've probably already looked at:
In a collection, the internal components always have the same data type, and are called elements. ... To create a collection variable, you either define a collection type and then create a variable of that type or use %TYPE.
In a record, the internal components can have different data types, and are called fields. You can access each field of a record variable by its name ... To create a record variable, you either define a RECORD type and then create a variable of that type or use %ROWTYPE or %TYPE.
So looking at what you said:
Here is what I believe is being declared here:
TYPE array_rec_type IS RECORD (gla_sub tblName.id%type);
This is a record, not a collection. In this case it has a single field called gla_sub which is indeed being declared using the data type of the id column from the tblName table. The use of %type means that, to some extent, you don't need to know what the data type actually is, and you may not have to change your code if that changes (if the size of a varchar2 column is increased, for instance).
v_closes_sc array_rec_type;
Correct - a variable of the newly created type is being created.
TYPE v_sc_type is TABLE OF v_closes_sc%TYPE INDEX BY BINARY_INTEGER;
This is a collection, specifically an associative array. It's a sparse array whose members are instance of the record type declared above, with a numeric index. That could also be declared using the type directly, as:
TYPE v_sc_type is TABLE OF array_rec_type INDEX BY BINARY_INTEGER;
sc_array v_sc_type;
Correct - a new variable is being created of that just-declared table type.
Having a record type with a single field seems a bit pointless, as you could have a collection based on the table column data type. Your existing code will be expecting that structure though, so changing it isn't quite trivial.
I'm converting a Delphi 5 / BDE application to Delphi XE7 / FireDAC. One of my forms has a TFDTable component that points to an Oracle view containing a group by clause in its create statement.
This used to work fine in the BDE application, but with FireDAC I'm getting this error.
ORA-01446: cannot select ROWID from, or sample, a view with DISTINCT,
GROUP BY, etc.
I understand the error I'm getting from Oracle, but I'm not selecting ROWID, FireDAC is! Is there a property in the TFDTable that I can set to prevent it from adding ROWID to the query? If not, how am I supposed to use this view?
FireDAC fetches ROWID because it tries to identify tuples in the resultset for possible updates. For stopping that just enable the ReadOnly option which will properly make the grouped view resultset read only (properly as one cannot just identify particular tuples if they are grouped in a resultset for updating).
The SQL command is generated in TFDPhysCommandGenerator.GenerateSelectTable method, if you wanted to know the source of this problem. There is appended generic unique tuple identifier to the select list according to the ReadOnly property setting (which is ROWID for Oracle DBMS).
Include fiMeta in FetchOptions.Items.
TFDQuery, TFDTable, TFDMemTable, and TFDCommand automatically retrieve
the unique identifying columns (mkPrimaryKeyFields) for the main
(first) table in the SELECT ... FROM ... statements, when fiMeta is
included in FetchOptions.Items. Note:
mkPrimaryKeyFields querying may be time consuming;
the application may need to explicitly specify unique identifying columns, when FireDAC fails to determine them correctly.
To explicitly specify columns, exclude fiMeta from FetchOptions.Items,
and use one of the following options:
set UpdateOptions.KeyFields to a ';' separated list of column names;
include pfInKey into the corresponding TField.ProviderFlags property.
When the application creates persistent fields, then initially
TField.ProviderFlags will be set correctly. After that, automatic
field setup will not happen, when the DB structure or query is
changed. You should manually update ProviderFlags to adjust the column
list. Also, if the primary key consists of several fields, then all of
them must be included into persistent fields. Row Identifying Columns
Alternatively, a row identifying column may be included into the
SELECT list. When FireDAC founds such columns, it will not retrieve
mkPrimaryKeyFields metadata and it will use this column. The supported
DBMSs are the following:
DBMS Row identifying column
Firebird DB_KEY
Informix ROWID
Interbase DB_KEY / RDB$DB_KEY
Oracle ROWID
PostgreSQL OID. The table must be created with OIDs.
SQLite ROWID
Source : http://docwiki.embarcadero.com/RADStudio/XE8/en/Unique_Identifying_Fields_%28FireDAC%29
I am using custom object types with Oracle PL/SQL, including several object types that inherit from a parent object. I have a TP_DOCUMENTS parent object, and child document types, such as TP_PUBLICATION, TP_CONTRACT, etc. We successfully created a table of TP_DOCUMENT and have added records of TP_PUBLICATION, TP_CONTRACT, and other child document records. However, I needed to create an additional type of document. Once I did this, it broke the DOCUMENTS table. How can I create additional child types, without breaking the table of the parent object (making me lose all the data previously contained in the parent object table!!)?
Here is some of my code:
create or replace TYPE "TP_DOCUMENT" AS OBJECT
(
...fields go here
) NOT FINAL
create or replace TYPE "TP_PUB_INSTRUCTION" UNDER TP_DOCUMENT()
CREATE TABLE DOCUMENTS OF TP_DOCUMENT
After creating these types (and others with additional fields), I created the table DOCUMENTs as shown above. I tried to create another sub-type, and the DOCUMENTS table broke.
MORE INFORMATION:
The error code message is as follows:
ORA-04063: table/view has errors
Cause: Attempt to execute a stored procedure or use a view that has errors. For stored procedures, the problem could be syntax errors or references to other, non-existent procedures. For views, the problem could be a reference in the view's defining query to a non-existent table. Can also be a table which has references to non-existent or inaccessible types.
Action: Fix the errors and/or create referenced objects as necessary.
Thank you!
UPDATE WITH ANSWER FROM COMMENTER BELOW:
I had unfortunately dropped a Sub-Type using the Force option. That likely was the cause for why my Documents table was corrupted. In the future, I will use the Validate command (see answer below).
Instead of FORCE you should use the VALIDATE option when dropping types:
VALIDATE
If you specify VALIDATE when dropping a type, then Oracle Database
checks for stored instances of this type within substitutable columns
of any of its supertypes. If no such instances are found, then the
database completes the drop operation.
This clause is meaningful only for subtypes. Oracle recommends the use
of this option to safely drop subtypes that do not have any explicit
type or table dependencies.
Here's an example:
create or replace type tp_document as object
(
a number
) not final;
create or replace type tp_pub_instruction under tp_document();
create table documents of tp_document;
--This fails with this error message:
--ORA-02303: cannot drop or replace a type with type or table dependents
drop type tp_pub_instruction;
--This works since there's no data with that type.
drop type tp_pub_instruction validate;