I'm using APEX 5 for the first time and having issue trying to insert items into my blob table.
I searched for many guides about creating File Browse's storage type to BLOB columns, which allows me to add MIME_TYPE, FILENAME, and CHARSET etc into my table. I am trying to create both upload and download feature.
But one thing that's been really confusing is creating DML processes, I could not understand where they getting their primary key item from, I somewhat understand that the DML primary key column are supposed to be my table's primary key?Errors keep coming up when I try to upload.
: https://i.stack.imgur.com/pj0G0.png
Any kind of help or tips would be greatly appreciated!
Below is my table to store blob
CREATE TABLE "MATERIALS"
( "ID" NUMBER NOT NULL ENABLE,
"MATERIAL_NAME" VARCHAR2(400),
"FILENAME" VARCHAR2(350),
"M_COURSE_ID" VARCHAR2(68),
"MIME_TYPE" VARCHAR2(255),
"DOC_SIZE" NUMBER,
"CHARSET" VARCHAR2(128),
"LAST_UPDATE_DATE" DATE,
"CONTENT" BLOB,
CONSTRAINT "MATERIALS_PK" PRIMARY KEY ("ID")
USING INDEX ENABLE
) NO INMEMORY
You'll need a item on your page to hold the id field. Your first process will populate it. I'm guessing you have a sequence?
Create a Hidden item, I'll call it P1_ID.
Your first process will populate it if it's empty. Create a process at the Processing step with a body of:
apex_util.set_session_state( 'P1_ID', mysequence.NEXTVAL );
Your DML process must run after this step, so drag them around or change the sequence if necessary.
Now set the Primary Key Item value to P1_ID in your DML process.
Related
Need some help to identify the reason for the below issue.
I have created a global temporary table as below:
Create global temporary table glo_temp_table
(
row_no NUMBER not null,
resource_id VARCHAR2(40),
company_id VARCHAR2(20),
);
This table’s data gets inserted during the runtime by a function which later used by a another function to fetch data using a cursor. This functionally works fine without any issue. Problem starts when I add an index below (to clear this is not done during the run time.):
CREATE INDEX SS ON glo_temp_table (resource_id);
Now no data will gets fetched by the cursor. Is there any specific reason for this behavior? How can I created a such a index to work properly?
Oracle db veriosn is 12c Release 12.1.0.1.0
This table only has the below constrain only.
alter table glo_temp_table
add constraint glo_temp_table_PK primary key (ROW_NO);
I've created a simple table in Oracle 12c like so:
CREATE TABLE TEST
(
ID NUMBER GENERATED ALWAYS AS IDENTITY,
TEXT VARCHAR2(2000 CHAR),
CONSTRAINT ID_PK PRIMARY KEY (ID)
);
Then I linked it in MS Access using ODBC driver. The problem is that when I input value into TEXT and click away both ID and TEXT show #Deleted. My value gets recorded in the database but I have to requery in MS Access in order to see it.
I also noticed that if I change the datatype of TEXT field to NUMBER, it works fine. After saving the record in MS Access both auto generated ID and value in TEXT field are there. I don't have to requery anything.
This happens only when inserting. Updating works just fine.
Please advise.
So, it would appear you already found the solution, but this is more of an explanation as to why it works that way. Simply speaking, if the base-table uses non-integer values as primary keys, Access rounds these integers to the nearest whole number and then (since it was not a numeric value) Access can no longer find the applicable records. So, changing the data type from TEXT to INTEGER in the table structure would give you your desired result.
Alternatively, if you're using a query to run through these, if you cannot change the keys in the Oracle table then altering the Access query type to a snapshot (in the query properties) will also bypass this problem. But from the sounds of it, this is not how you are utilizing the data.
In my case, the Oracle ODBC driver (using the rather old version 11.02.00.01 that otherwise works ok and Microsoft Access 2016 32Bit) seems to use the unique indices and not the primary key constraint for determining the primary key.
I had a field with NUMBER(11) as PK with an unique index, then added a VARCHAR2 field with another unique index. The name of the index of the VARCHAR2 field was alphabetically before that of the NUMBER field.
Now, the linked table in Microsoft Access showed the VARCHAR2 field as primary key and I had the problem with '#Deleted' appearing after entering & saving a record as you describe.
After renaming the unique index on the NUMBER field in Oracle to be alphabetically before that of the VARCHAR2 field and re-linking the table in Microsoft Acces, the NUMBER field was the primary key again in Microsoft Access and the '#Deleted' problem was solved.
I'm learning Oracle and I had a problem. I have my "Chat" table:
CREATE TABLE chat (
id_chat NUMBER,
id_user NUMBER,
start_chat DATE,
end_chat DATE
);
Now, I created a trigger so that it does not allow me to enter a "Chat" if an old one was already registered with the same id_user. This is my trigger:
create or replace trigger distChat
before insert on Chat
for each row
begin
if :new.id_user = :old.id_user then
Raise_Application_Error(-20099,'YOU CAN'T INSERT DUPLICATED DATA.');
end if;
end distChat;
But still it still allows me to enter Chat with the same user code. Any help or recommendation to improve my trigger that does not work.
Thank you.
Don't use a TRIGGER.
Two reasons:
Oracle provides a mechanism for preventing duplicates
Triggers are expensive, and another database object to maintain
Do this
ALTER table CHAT ADD CONSTRAINT xpk_chat PRIMARY KEY ( ID_CHAT );
I don't know your data model, but I think you want ID_CHAT to distinguish a chat. If you do this for ID_USER, then a user couldn't ever have more than one chat...and who would want to use that system? If I'm wrong, just change the column referenced in the ALTER command above.
Now your table will have a constraint that prevents duplicate values on ID_CHAT column. This is called a PRIMARY KEY (Docs)
Additionally, you will have an INDEX, so querying your CHAT's by their ID value could be quicker.
P.S. Your Trigger isn't doing what you want it to do. If you were to do it with a trigger you would need to raise the exception if :new.id_user in (select distinct id_user from chat)...so basically if the ID resulting in the INSERT was already found in the table, there would be an exception. The beauty of the PK constraint is, that the database does this FOR YOU.
Something strange happened to me today ,my friends(developers) said its probably a bug ... Usually when I want to see the DDL of a table in PL/SQL , I right-click on the table and then I click on view and I get the DDL .However, there is another way I can get the DDL of a table and by right clicking on the table and there something called DBMS_METADATA then I put my cursor on it and it will show me DDL. In the image that I upload there a difference between the DBMS_METADATA and the 'view' .Number 1 represents the 'view' and the 2 represents the DBMS_METADATA, if you notice there is a huge difference between the two .The first one shows column organization_code its not null (because its not checked) but the 2nd one shows organization_code is null. this made the developers confused, which one they should count on ? .But after testing the column its not null. I should mention that is column is a primary key so it should be NOT null why in medata showed a wrongs information ? does that happened to anyone before ?(by the way i am using 11g)
A column used for a primary key cannot be null1. However, that restriction can be enforced solely through a primary key constraint, and does not require a separate not null constraint. The IDE, PL/SQL Developer, is showing you a generally more useful combination of primary key constraints and not null constraints. DBMS_METADATA is showing you exactly how the tables were specified, which is irrelevant unless you plan on dropping the primary keys.
create table table1(a number not null primary key);
create table table2(a number primary key);
begin
dbms_metadata.set_transform_param(dbms_metadata.session_transform,
'SEGMENT_ATTRIBUTES',false);
end;
/
select dbms_metadata.get_ddl('TABLE', 'TABLE1') from dual;
CREATE TABLE "JHELLER"."TABLE1"
( "A" NUMBER NOT NULL ENABLE,
PRIMARY KEY ("A") ENABLE
)
select dbms_metadata.get_ddl('TABLE', 'TABLE2') from dual;
CREATE TABLE "JHELLER"."TABLE2"
( "A" NUMBER,
PRIMARY KEY ("A") ENABLE
)
In PL/SQL Developer, neither column has Nullable checked.
1 Unless you use a novalidated non-unique index, which is extremely rare.
I'm trying to create a new row in a table. There are two constraints on the table -- one is on the key field (DB_ID), the other constrains a value to be one of several the the field ENV. When I do an insert, I do not include the key field as one of the fields I'm trying to insert, yet I'm getting this error:
unique constraint (N390.PK_DB_ID) violated
Here's the SQL that causes the error:
insert into cmdb_db
(narrative_name, db_name, db_type, schema, node, env, server_id, state, path)
values
('Test Database', 'DB', 'TYPE', 'SCH', '', 'SB01', 381, 'TEST', '')
The only thing I've been able to turn up is the possibility that Oracle might be trying to assign an already in-use DB_ID if rows were inserted manually. The data in this database was somehow restored/moved from a production database, but I don't have the details as to how that was done.
Any thoughts?
Presumably, since you're not providing a value for the DB_ID column, that value is being populated by a row-level before insert trigger defined on the table. That trigger, presumably, is selecting the value from a sequence.
Since the data was moved (presumably recently) from the production database, my wager would be that when the data was copied, the sequence was not modified as well. I would guess that the sequence is generating values that are much lower than the largest DB_ID that is currently in the table leading to the error.
You could confirm this suspicion by looking at the trigger to determine which sequence is being used and doing a
SELECT <<sequence name>>.nextval
FROM dual
and comparing that to
SELECT MAX(db_id)
FROM cmdb_db
If, as I suspect, the sequence is generating values that already exist in the database, you could increment the sequence until it was generating unused values or you could alter it to set the INCREMENT to something very large, get the nextval once, and set the INCREMENT back to 1.
Your error looks like you are duplicating an already existing Primary Key in your DB. You should modify your sql code to implement its own primary key by using something like the IDENTITY keyword.
CREATE TABLE [DB] (
[DBId] bigint NOT NULL IDENTITY,
...
CONSTRAINT [DB_PK] PRIMARY KEY ([DB] ASC),
);
It looks like you are not providing a value for the primary key field DB_ID. If that is a primary key, you must provide a unique value for that column. The only way not to provide it would be to create a database trigger that, on insert, would provide a value, most likely derived from a sequence.
If this is a restoration from another database and there is a sequence on this new instance, it might be trying to reuse a value. If the old data had unique keys from 1 - 1000 and your current sequence is at 500, it would be generating values that already exist. If a sequence does exist for this table and it is trying to use it, you would need to reconcile the values in your table with the current value of the sequence.
You can use SEQUENCE_NAME.CURRVAL to see the current value of the sequence (if it exists of course)