Loading type in repository tables

How can I find the loading type of the mappings in the repository tables? I am using OWB 10.2.

Hi Luciene,
Basically all information that you need is stored in OWBRT_SYS.ALL_IV_XFORM_MAP_% views. Difference between ALL_RT_OBJECTS view and ALL_IV_XFORM_MAPS is taht first holds information about all deployed objects, but ALL_IV_XFORM_MAPS holds information about all mappings in owb (deployed, new - not deployed etc.). Property information is stored in ALL_IV_XFORM_MAP_PROPERTIES view. But unfortunately i can't access directly this view, because this view throws a exception (ORA-22835: Buffer too small for CLOB to CHAR or BLOB to RAW conversion (actual: 7533, maximum: 4000)). It seams to me, that this error is related to RDBMS bug (metalink: Bug No. 5610195). This view is based on CMPSTRINGPROPERTYVALUE_X view, so i don't know relations between fields and values, you can try to search trough these views.
Regards

Similar Messages

Does the advanced queue support setting the pay load type as array/table?

Does the advanced queue support setting the pay load type as array/table?
if yes, how to write the enqueue script, I tried to write the following the script to enqueue, but failed, pls help to review it . Thanks...
------Create payload type
create or replace TYPE "SIMPLEARRAY" AS VARRAY(99) OF VARCHAR(20);
------Create queue table
BEGIN DBMS_AQADM.CREATE_QUEUE_TABLE(
Queue_table => 'LUWEIQIN.SIMPLEQUEUE',
Queue_payload_type => 'LUWEIQIN.SIMPLEARRAY',
storage_clause => 'PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 TABLESPACE USERS',
Sort_list => 'ENQ_TIME',
Compatible => '8.1.3');
END;
------Create queue
BEGIN DBMS_AQADM.CREATE_QUEUE(
Queue_name => 'LUWEIQIN.SIMPLEQUEUE',
Queue_table => 'LUWEIQIN.SIMPLEQUEUE',
Queue_type => 0,
Max_retries => 5,
Retry_delay => 0,
dependency_tracking => FALSE);
END;
-------Start queue
BEGIN
dbms_aqadm.start_queue(queue_name => 'LUWEIQIN.SIMPLEQUEUE', dequeue => TRUE, enqueue => TRUE);
END;
-------Enqueue
DECLARE
v_enqueueoptions dbms_aq.enqueue_options_t;
v_messageproperties dbms_aq.message_properties_t;
p_queue_name VARCHAR2(40);
Priority INTEGER;
Delay INTEGER;
Expiration INTEGER;
Correlation VARCHAR2(100);
Recipientlist dbms_aq.aq$_recipient_list_t;
Exceptionqueue VARCHAR2(100);
p_queue_name VARCHAR2(40);
p_msg VARCHAR2(40);
p_payload LUWEIQIN.SIMPLEARRAY;
BEGIN
p_payload(1) := 'aa';
p_payload(2) := 'bb';
SYS.DBMS_AQ.ENQUEUE(queue_name => 'LUWEIQIN.SIMPLEQUEUE',enqueue_options => v_enqueueoptions, message_properties => v_messageproperties, msgid => p_msg, payload => p_payload);
END;
------Get error
Error starting at line 1 in command:
DECLARE
v_enqueueoptions dbms_aq.enqueue_options_t;
v_messageproperties dbms_aq.message_properties_t;
p_queue_name VARCHAR2(40);
Priority INTEGER;
Delay INTEGER;
Expiration INTEGER;
Correlation VARCHAR2(100);
Recipientlist dbms_aq.aq$_recipient_list_t;
Exceptionqueue VARCHAR2(100);
p_queue_name VARCHAR2(40);
p_msg VARCHAR2(40);
p_payload LUWEIQIN.SIMPLEARRAY;
BEGIN
p_payload(1) := 'aa';
p_payload(2) := 'bb';
SYS.DBMS_AQ.ENQUEUE(queue_name => 'LUWEIQIN.SIMPLEQUEUE',enqueue_options => v_enqueueoptions, message_properties => v_messageproperties, msgid => p_msg, payload => p_payload);
END;
Error report:
ORA-06550: line 17, column 3:
PLS-00306: wrong number or types of arguments in call to 'ENQUEUE'
ORA-06550: line 17, column 3:
PL/SQL: Statement ignored
06550. 00000 - "line %s, column %s:\n%s"
*Cause: Usually a PL/SQL compilation error.
*Action:

but when I use the following script to enqueue get error. Pls help to review. Thanks...
DECLARE
v_enqueueoptions dbms_aq.enqueue_options_t;
v_messageproperties dbms_aq.message_properties_t;
p_queue_name VARCHAR2(40);
Priority INTEGER;
Delay INTEGER;
Expiration INTEGER;
Correlation VARCHAR2(100);
Recipientlist dbms_aq.aq$_recipient_list_t;
Exceptionqueue VARCHAR2(100);
p_queue_name VARCHAR2(40);
p_msg VARCHAR2(40);
p_payload LUWEIQIN.SIMPLEARRAY;
BEGIN
p_payload(1) := 'aa';
p_payload(2) := 'bb';
SYS.DBMS_AQ.ENQUEUE(queue_name => 'LUWEIQIN.SIMPLEQUEUE',enqueue_options => v_enqueueoptions, message_properties => v_messageproperties, msgid => p_msg, payload => p_payload);
END;
------Get error
Error starting at line 1 in command:
DECLARE
v_enqueueoptions dbms_aq.enqueue_options_t;
v_messageproperties dbms_aq.message_properties_t;
p_queue_name VARCHAR2(40);
Priority INTEGER;
Delay INTEGER;
Expiration INTEGER;
Correlation VARCHAR2(100);
Recipientlist dbms_aq.aq$_recipient_list_t;
Exceptionqueue VARCHAR2(100);
p_queue_name VARCHAR2(40);
p_msg VARCHAR2(40);
p_payload LUWEIQIN.SIMPLEARRAY;
BEGIN
p_payload(1) := 'aa';
p_payload(2) := 'bb';
SYS.DBMS_AQ.ENQUEUE(queue_name => 'LUWEIQIN.SIMPLEQUEUE',enqueue_options => v_enqueueoptions, message_properties => v_messageproperties, msgid => p_msg, payload => p_payload);
END;
Error report:
ORA-06550: line 17, column 3:
PLS-00306: wrong number or types of arguments in call to 'ENQUEUE'
ORA-06550: line 17, column 3:
PL/SQL: Statement ignored
06550. 00000 - "line %s, column %s:\n%s"
*Cause: Usually a PL/SQL compilation error.
*Action:

DataSource 2LIS_17_I3HDR not loading all order types in setup tables

I am trying to setup data source 2LIS_17_I3HDR. I have initialized the setup tables and I am only getting 609 records in RSA3. The problem is that all the records are from only two order types. I have run the setup table initialization wide open so i'm not sure why the setup table only contains a subset of our orders.
Obviously we have numerous other order types that I am expecting to be loaded into the setup tables (AFIH has around 180k entries). Where can I configure which orders get loaded into the setup tables?
Thanks,
Chris

That is an interesting thread. I have a few questions though:
-How can I determine which order types are maintenance orders? When I look at transaction OIOA for Order Type Configuration I see that order category for numerous order types including the order types currently being loaded as having an order category of "30 Maintenance order" so I am unclear which field I need to be looking at for orders because in OIOA I see at least 8 other order types that look identical to the two order types being loaded. When I look in IW39 I am seeing orders under order types are being loaded and under order types that aren't being loaded
-In the linked thread it appears that the person with the issue was trying to pull detail data without header data. I believe I am doing the opposite with these orders. I am pulling the header data first. Currently when I run 2LIS_17_OPER (I think this is the order detail DS) in RS3 I get no data. Am I misunderstanding how the PM Order data sources work?
Thanks,
Chris

INSERT Loading Type not working correctly?

Hi,
I'm using ver. 9.2.0.2.8 for the owb client, and ver. 9.2.0.2 for the repository. I'm currently encountering this problem when using the INSERT loading type for loading data into one of my staging tables. It's a simple simple mapping really:
I have a source table (A) that maps to a filter operator, which is then mapped to a staging table(B).
The problem is, when I run the mapping to INSERT data from A into an already populated B, not all the desired records are inserted. Weird thing is, when I run the code from generating the intermediate result in TOAD or whatever, I get the desired results. So that kinda rules out any doubts on the select statement generated by OWB.
Out of 23 records I get like 6.. just 6 of the 23 records I was hoping to be inserted into B.
And yes, none of the remaining 17 records are present in A, so INSERT should (ideally) work fine and carry out inserting all the 23 records.
Any ideas? ..

Hi JP,
Thank you very much for helpin out, I tried what you told me and here's what I got:
Starting Execution STG_MAP_FILTER_DCS_IRREG
Starting Task STG_MAP_FILTER_DCS_IRREG
ORA-12801: error signaled in parallel query server P012
ORA-02291: integrity constraint (RTOWNER.FK_RTER_RTA) violated - parent key not found
ORA-06512: at "RTOWNER.WB_RT_MAPAUDIT", line 338
ORA-01403: no data found
ORA-06512: at "RTOWNER.WB_RT_MAPAUDIT", line 1736
ORA-06512: at "RTOWNER.WB_RT_MAPAUDIT", line 2625
ORA-06512: at "TOPSSTAGE.STG_MAP_FIL_R_TGT0_719337", line 1443
ORA-06512: at "TOPSSTAGE.STG_MAP_FIL_R_TGT0_719337", line 2076
ORA-06512: at "TOPSSTAGE.STG_MAP_FILTER_DCS_IRREG", line 482
ORA-06512: at "TOPSSTAGE.STG_MAP_FILTER_DCS_IRREG", line 813
ORA-06512: at line 1
Completing Task STG_MAP_FILTER_DCS_IRREG
Completing Execution STG_MAP_FILTER_DCS_IRREG
..I wonder what it means, hehe.

Initial load failing between identical tables. DEFGEN skewed and fixable?

Initial load failing between identical tables. DEFGEN skewed and fixable?
Error seen:
2013-01-28 15:23:46 WARNING OGG-00869 [SQL error 0 (0x0)][HP][ODBC/MX Driver] DATETIME FIELD OVERFLOW. Incorrect Format or Data. Row: 1 Column: 11.
Then compared the discard record against a select * on the key column.
Mapping problem with insert record (target format)...
**** Comparing Discard contents to Select * display
ABCHID = 3431100001357760616974974003012 = 3431100001357760616974974003012
*!!! ABCHSTEPCD = 909129785 <> 9 ???*
ABCHCREATEDDATE = 2013-01-09 13:43:36 = 2013-01-09 13:43:36
ABCHMODIFIEDDATE = 2013-01-09 13:43:36 =2013-01-09 13:43:36
ABCHNRTPUSHED = 0 = 0
ABCHPRISMRESULTISEVALUATED = 0 = 0
SABCHPSEUDOTERM = 005340 = 005340
ABCHTERMID = TERM05 = TERM05
ABCHTXNSEQNUM = 300911112224 = 300911112224
ABCHTIMERQSTRECVFROMACQR = 1357799914310 = 1357799914310
*!!! ABCTHDATE = 1357-61-24 00:43:34 <> 2013-01-09 13:43:34*
ABCHABCDATETIME = 2013-01-09 13:43:34.310000 = 2013-01-09 13:43:34.310000
ABCHACCOUNTABCBER =123ABC = 123ABC
ABCHMESSAGETYPECODE = 1210 = 1210
ABCHPROCCDETRANTYPE = 00 = 00
ABCHPROCCDEFROMACCT = 00 = 00
ABCHPROCCDETOACCT = 00 = 00
ABCHRESPONSECODE = 00 = 00
…. <snipped>
Defgen comes out same when run against either table.
Also have copied over and tried both outputs from DEFGEN.
+- Defgen version 2.0, Encoding ISO-8859-1
* Definitions created/modified 2013-01-28 15:00
* Field descriptions for each column entry:
* 1 Name
* 2 Data Type
* 3 External Length
* 4 Fetch Offset
* 5 Scale
* 6 Level
* 7 Null
* 8 Bump if Odd
* 9 Internal Length
* 10 Binary Length
* 11 Table Length
* 12 Most Significant DT
* 13 Least Significant DT
* 14 High Precision
* 15 Low Precision
* 16 Elementary Item
* 17 Occurs
* 18 Key Column
* 19 Sub Data Type
Database type: SQLMX
Character set ID: ISO-8859-1
National character set ID: UTF-16
Locale: en_EN_US
Case sensitivity: 14 14 14 14 14 14 14 14 14 14 14 14 11 14 14 14
Definition for table RT.ABC
Record length: 1311
Syskey: 0
Columns: 106
ABCHID 64 34 0 0 0 0 0 34 34 34 0 0 32 32 1 0 1 3
ABCHSTEPCD 132 4 39 0 0 0 0 4 4 4 0 0 0 0 1 0 0 0
ABCHCREATEDDATE 192 19 46 0 0 0 0 19 19 19 0 5 0 0 1 0 0 0
ABCHMODIFIEDDATE 192 19 68 0 0 0 0 19 19 19 0 5 0 0 1 0 0 0
ABCHNRTPUSHED 130 2 90 0 0 0 0 2 2 2 0 0 0 0 1 0 0 0
ABCHPRISMRESULTISEVALUATED 130 2 95 0 0 0 0 2 2 2 0 0 0 0 1 0 0 0
ABCHPSEUDOTERM 0 8 100 0 0 0 0 8 8 8 0 0 0 0 1 0 0 0
ABCTERMID 0 16 111 0 0 0 0 16 16 16 0 0 0 0 1 0 0 0
ABCHTXNSEQNUM 0 12 130 0 0 0 0 12 12 12 0 0 0 0 1 0 0 0
ABCHTIMERQSTRECVFROMACQR 64 24 145 0 0 0 0 24 24 24 0 0 22 22 1 0 0 3
ABCTHDATE 192 19 174 0 0 0 0 19 19 19 0 5 0 0 1 0 0 0
ABCHABCDATETIME 192 26 196 0 0 1 0 26 26 26 0 6 0 0 1 0 0 0
ABCHACCOUNTABCER 0 19 225 0 0 1 0 19 19 19 0 0 0 0 1 0 0 0
ABCHMESSAGETYPECODE 0 4 247 0 0 1 0 4 4 4 0 0 0 0 1 0 0 0
ABCHPROCCDETRANTYPE 0 2 254 0 0 1 0 2 2 2 0 0 0 0 1 0 0 0
ABCHPROCCDEFROMACCT 0 2 259 0 0 1 0 2 2 2 0 0 0 0 1 0 0 0
ABCHPROCCDETOACCT 0 2 264 0 0 1 0 2 2 2 0 0 0 0 1 0 0 0
ABCHRESPONSECODE 0 5 269 0 0 1 0 5 5 5 0 0 0 0 1 0 0 0
… <snipped>
The physical table shows a PACKED REC 1078
And table invoke is:
-- Definition of table ABC3.RT.ABC
-- Definition current Mon Jan 28 18:20:02 2013
ABCHID NUMERIC(32, 0) NO DEFAULT HEADING '' NOT
NULL NOT DROPPABLE
, ABCHSTEPCD INT NO DEFAULT HEADING '' NOT NULL NOT
DROPPABLE
, ABCHCREATEDDATE TIMESTAMP(0) NO DEFAULT HEADING '' NOT
NULL NOT DROPPABLE
, ABCHMODIFIEDDATE TIMESTAMP(0) NO DEFAULT HEADING '' NOT
NULL NOT DROPPABLE
, ABCHNRTPUSHED SMALLINT DEFAULT 0 HEADING '' NOT NULL NOT
DROPPABLE
, ABCHPRISMRESULTISEVALUATED SMALLINT DEFAULT 0 HEADING '' NOT NULL NOT
DROPPABLE
, ABCHPSEUDOTERM CHAR(8) CHARACTER SET ISO88591 COLLATE
DEFAULT NO DEFAULT HEADING '' NOT NULL NOT DROPPABLE
, ABCHTERMID CHAR(16) CHARACTER SET ISO88591 COLLATE
DEFAULT NO DEFAULT HEADING '' NOT NULL NOT DROPPABLE
, ABCHTXNSEQNUM CHAR(12) CHARACTER SET ISO88591 COLLATE
DEFAULT NO DEFAULT HEADING '' NOT NULL NOT DROPPABLE
, ABCHTIMERQSTRECVFROMACQR NUMERIC(22, 0) NO DEFAULT HEADING '' NOT
NULL NOT DROPPABLE
, ABCTHDATE TIMESTAMP(0) NO DEFAULT HEADING '' NOT
NULL NOT DROPPABLE
, ABCHABCDATETIME TIMESTAMP(6) DEFAULT NULL HEADING ''
, ABCHACCOUNTNABCBER CHAR(19) CHARACTER SET ISO88591 COLLATE
DEFAULT DEFAULT NULL HEADING ''
, ABCHMESSAGETYPECODE CHAR(4) CHARACTER SET ISO88591 COLLATE
DEFAULT DEFAULT NULL HEADING ''
, ABCHPROCCDETRANTYPE CHAR(2) CHARACTER SET ISO88591 COLLATE
DEFAULT DEFAULT NULL HEADING ''
, ABCHPROCCDEFROMACCT CHAR(2) CHARACTER SET ISO88591 COLLATE
DEFAULT DEFAULT NULL HEADING ''
, ABCHPROCCDETOACCT CHAR(2) CHARACTER SET ISO88591 COLLATE
DEFAULT DEFAULT NULL HEADING ''
, ABCHRESPONSECODE CHAR(5) CHARACTER SET ISO88591 COLLATE
DEFAULT DEFAULT NULL HEADING ''
…. Snipped
I suspect that the fields having subtype 3 just before the garbled columns is a clue, but not sure what to replace with or adjust.
Any and all help mighty appreciated.

Worthwhile suggestion, just having difficulty applying.
I will tinker with it more. But still open to more suggestions.
=-=-=-=-
Oracle GoldenGate Delivery for SQL/MX
Version 11.2.1.0.1 14305084
NonStop H06 on Jul 11 2012 14:11:30
Copyright (C) 1995, 2012, Oracle and/or its affiliates. All rights reserved.
Starting at 2013-01-31 15:19:35
Operating System Version:
NONSTOP_KERNEL
Version 12, Release J06
Node: abc3
Machine: NSE-AB
Process id: 67895711
Description:
** Running with the following parameters **
2013-01-31 15:19:40 INFO OGG-03035 Operating system character set identified as ISO-8859-1. Locale: en_US_POSIX, LC_ALL:.
Comment
Comment
REPLICAT lodrepx
ASSUMETARGETDEFS
Source Context :
SourceModule : [er.init]
SourceID : [home/ecloud/sqlmx_mlr14305084/src/app/er/init.cpp]
SourceFunction : [get_infile_params]
SourceLine : [2418]
2013-01-31 15:19:40 ERROR OGG-00184 ASSUMETARGETDEFS is not supported for SQL/MX ODBC replicat.
2013-01-31 15:19:45 ERROR OGG-01668 PROCESS ABENDING.

How to load Data of 2 tables into 1 dimension? Snowflake?

I want to load data of scott.dept & scott.emp into one dimension using AWM.
Don't want to join the 2 tables into 1, don't want to create a view either.
Is there a way?
I tried to select 'snowflake' as the dimension table type in the mapping editor.
but the data was not loaded properly.
only the dept data got loaded.
Any idea?

I created a new dimension called DEPT and added two levels : DEPT and EMP.
In the mapping I used the setting 'Other' rather than 'snowflake'. It requires a bit more mapping as you have to set the mapping details for each attribute and the member/parent details. This worked and loaded the data correctly. The mapping looks a bit strange as their are lines everywhere. But it works.
However, I then started playing with this to try and expand it a little further and things started to get very difficult
1) Manager- I tried to add an additional level to map the manager but this would not work because you cannot find the department for the manager from the existing table. If you try and use the Dept column what will be allocated is the department for the last employee in that table with the selected manager.
2) All - there is no way to add an 'All' level. Most OLAP dimensions require an 'All' or top level node to allow the data to be aggregate to a useful total. May be this should be an automatic feature of AWM - A possible enhancement request? Who knows it might be in the next release of AWM which is due shortly.
3) It is not possible to save the mapping - once you have created the mapping if you click on any other node in the AWM tree and then click on mapping again the type of dimension table reverts to 'Star Schema'. If you change the type to 'Other' some of the mappings get lost. This looks like a bug.
4) If you want to make this a value based dimension then you have to use the natural keys in the data. If you use surrogate keys then you can only create a level based dimension.
Hope this helps
Keith

Issue with UPDATE/INSERT Loading type

Hi ,
i am using the owb11g
all that i am trying to do is load in to Target table using update/insert loading type.
there are duplicates in the src table, and i have PK defined on the Target table.
when ever i execute the mapping it says NO DATA TO READ FROM SOCKET.
what is the solution? can there be a better way of doing this?
please help

why do you keep posting duplicate posts for the same problem?
Please continue with your post (link below)
No more data to read from socket

How to find out Mapping Loading type using db query

Is there a way to find out mapping loading type using a database query.
Is there a table in database which stores loading type information?
Thanks,
Niranjan

hi,
i found the below
select
        comp.map_name
       ,comp.map_component_id             comp_map_component_id
       ,comp.operator_type                comp_operator_type
       ,comp.data_entity_id               comp_data_entity
       ,comp.data_entity_name             comp_data_ename
       ,comp.data_entity_type             comp_data_etype
       ,param.map_component_name          param_comp_name
       ,param.parameter_id                param_par_id
       ,param.parameter_name              param_par_name
       ,param.parameter_group_name        param_par_gr_name
       ,param.parameter_type              param_par_type
       ,param.position                    param_position
       ,param.data_type                   param_data_type
       ,param.transformation_expression   param_transform
       ,param.data_item_id                param_data_item_id
       ,param.data_item_name              param_data_item_name
       ,param.source_parameter_name       param_src_parameter
       ,nvl2(param.source_parameter_name,'TARGET','SOURCE') param_INFO
       ,param.map_component_id             param_map_component_id
       ,md.map_component_id                md_map_component_id
       ,md.map_component_name              md_map_component_name
       ,md.parameter_name                  md_parameter_name
       ,md.parameter_id                    md_parameter_id
       ,md.position                        md_position
       ,md.transformation_expression       md_transformation
       ,md.description                     md_description
       ,md.source_expression               md_source_expression
       ,mp.MAP_COMPONENT_ID                    mp_map_component_id
       ,mp.MAP_COMPONENT_NAME                  mp_map_component_name
       ,mp.PROPERTY_ID                        mp_property_id
       ,mp.PROPERTY_NAME                      mp_property_name
       ,mp.PROPERTY_GROUP_NAME                mp_property_group_name
       ,mp.BUSINESS_NAME                      mp_business_name
       ,mp.PROPERTY_VALUE                  mp_property_value
       ,mp.DESCRIPTION                     mp_description
from all_iv_xform_map_components comp,
     all_iv_xform_map_parameters param,
     ALL_IV_XFORM_MAP_DETAILS md,
     ALL_IV_XFORM_MAP_PROPERTIES mp
where mp.business_name                  = 'DATAENTITY.PARMETERS.LOADTYPE'
and param.map_component_id           = comp.map_component_id
and param.map_component_id           = md.map_component_id(+)
and param.parameter_id               = md.parameter_id (+)
and md.map_component_id              = mp.map_component_id (+)i think it contains what we require;
can you check on your side?
rgds

Load Type as INSERT/UPDATE ?

Hi,
I would like to use load type INSERT/UPDATE. So would it create any performance issue when compareted to the load type as INSERT. Is it considerable?
Thank you,
Regards,
Gowtham Sen.

Hi
That depends completely on the data you are reading in (your source) and how often the row exists in the target table. The idea to choose between INSERT/UPDATE and UPDATE/INSERT is if you know that most of the data is new you choose the first one but if most of the data already exists you choose the latter. But the code generated in the end will be a MERGE statement so it won't matter much.
To make sure you get the best performance in case your ETL will have to to many updates as well as inserts is to make sure that the matching criteria on the target is indexed.
Borkur

Hyperion Analyzer Repository Tables

I am creating a cross-reference report that shows me the access privileges assigned to each report in Hyperion Analyzer. I found that the information resides in the HsDsAttributes and HsDsACL SQL Server repository tables but I have no metadata for these tables. Does anyone know what the values in the columns for these tables are defined as? Specifically the class, type, and intval columns in the HsDsAttributes table.
Thanks.

Hi John,
Thanks for sharing the pdf related to the HSP tables.
When a FORM is submitted in planning application and the Final submission status= "Pick Yes/No" should be stored in the HSP table. As per the pdf which you have provided for the planning tables- Looks like the HYP_PLANAPP3.HSP_JOB_STATUS and HYP_PLANAPP3.HSP_AUDIT_RECORDS should have this information.
example if the Form is saved for final submission status = Yes, this value should be stored some where in the HSP table, and my guess is under HYP_PLANAPP3.HSP_JOB_STATUS and column RUN_STATUS with values like 0 or 1. Please correct me If I am wrong.
Sorry I might not be using the correct Hyperion terms.
Thanks,
Sikandar

Loading data into a table

I am loading data into a table I created which includes a column "Description" with a data type VARCHAR2(1000). When I go to load the data which is less than 1000 characters I receive the following error message:
Record 38: Rejected - Error on table SSW_INPUTS, column DESCRIPTION.
Field in data file exceeds maximum length
I have increased the size of the column but that does not seem to fix the error. Does anyone know what this error means? Another thought is that I have created the "Description" column to large...which can't be true because I should receive the error when I create the table. Plus I already inputted data into a similar table with similar data and had no problems!
Someone please help...
Thank you,
April.

Note that I'm assuming Oracle8(i) behavior. Oracle9 may treat Unicode differently.
Are you inserting Unicode data into the table? Declaring a variable as varchar2(1000) indicates that Oracle should reserve 1000 bytes for data. If you're inserting UTF-8 encoded data, each character may take up to 3 bytes to store. Thus, 334 characters of data could theoretically overflow a varchar2(1000) variable.
Note that UTF-8 is designed so that the most commonly used characters are stored in 1 byte, less commonly used characters are stored in 2 bytes, and the remainder is stored in 3 bytes. On average, this will require less space than the more familiar UCS-2 encoding which stores every character as 2 bytes of data.
Justin

OWB -- Load Type Property Setting

Hi,
Mapping is done in OWB for source(Sybase) and Target(Oracle).
Now, can any one please tell that what values are required to set for source(operater -- load type) and target(operater -- load type).
Thanks in advance.
Amit Shah.

Hi Amit,
You can go to the target table and do a right click...choose operator properties...There you have the option of changing the loading stratergy like insert or insert\update etc...
you can also decide on how to load your target table...i.e insert w.r.t your PK or UI...
Regards
Bharath

Full To Delta (changing load type)

Hello Everybody
I am planning to convert few laad type from FUll to delta because its just taking too long to load. But here are my questions.
Besides the fact that (full load)it's a business requrement(snapshot); i cannot change it right or there is still a way.
1. what are the technical considerations for converting full load from a dso to a cube . If ths dso is getting a full load itself does it have to be set to overwrite to further do a delta to a cube. what if the dso is getting delta load . do i have to consider from source to dso as well if its delta or full; how does it affect it.
2. what happens to the existing laods/requests in a cube/dso if i change the load type. (does it get affected)
thanks

Hi,
1. When changing the data load to delta from DSO to cube, just you can go ahead an do init. Since the base leve is DSO it doesnot matter if the base level data load is full or delta. Also make sure the DSO is standard one. If the source is DSO there is no problem in converting from full to delta.
2. Make sure only one full load exist in cube. Then do a init and going further you can pull delta. The existing data in DSO will not be affected or cube data. Since delta will fetch data from change log table there will not an issue.
Regards
Akhan

Types of database tables

types of database tables and one line definition

Hi
Table Types
Standard table:
The key access to a standard table uses a sequential search. The time required for an access is linearly dependent on the number of entries in the internal table.
You should usually access a standard table with index operations.
Sorted table:
The table is always stored internally sorted by its key. Key access to a sorted table can therefore use a binary search. If the key is not unique, the entry with the lowest index is accessed. The time required for an access is logarithmically dependent on the number of entries in the internal table.
Index accesses to sorted tables are also allowed. You should usually access a sorted table using its key.
Hash table:
The table is internally managed with a hash procedure. All the entries must have a unique key. The time required for a key access is constant, that is it does not depend on the number of entries in the internal table.
You cannot access a hash table with an index. Accesses must use generic key operations (SORT, LOOP, etc.).
Index table:
The table can be a standard table or a sorted table.
Index access is allowed to such an index table. Index tables can be used to define the type of generic parameters of a FORM (subroutine) or a function module.
Just have a look at these links:
http://help.sap.com/saphelp_nw04/helpdata/en/90/8d7304b1af11d194f600a0c929b3c3/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/74/83015785d811d295a800a0c929b3c3/frameset.htm
Pooled Tables, Table Pools, Cluster Tables, and Table Clusters
These types of tables are not transparent in the sense that they are not legible or manageable directly using the underlying database system tools. They are managed from within the R/3 environment from the ABAP dictionary and also at runtime when they are loaded into application memory.Pool and cluster tables are logical tables. Physically, these logical tables are arranged as records of transparent tables. The pool and cluster tables are grouped together in other tables, which are of the transparent type. The tables that group together pool tables are known as table pools, or just pools; similarly, table clusters, or just
clusters, are the tables which group cluster tables.Not all operations that can be performed over transparent tables can be executed over pool or cluster tables.
For instance, you can manage these tables using Open SQL calls from ABAP, but not Native SQL.These tables are meant to be buffered and loaded in memory, because they are commonly used for storing internal control information and other types of data with no external (business) relevance. SAP recommends that tables of pool or cluster type be used exclusively for control information such as
program parameters, documentation, and so on. Transaction and application data should be stored in transparent tables.
Table Pools
From the point of view of the underlying DBMS as from the point of view of the ABAP dictionary, a table pool is a transparent table containing a group of pooled tables which, when created, were assigned to this table pool.
Field Type Description
TABNAME CHAR(10) Table name
VARKEY CHAR(n) Maximum key length n =< 110
DATALN INT2(5) Length of the VARDATA record returned
VARDATA RAW(m) Maximum length of the data varies according to DBMS
Table Clusters
Similarly to pooled tables, cluster tables are logical tables which, when created, are assigned to a table cluster. Therefore, a table cluster, or just cluster, groups together several tables of type clusters.Several logical rows from different cluster tables are brought together in a single physical record. The records
from the cluster tables assigned to a cluster are thus stored in a single common table in the database.A cluster contains a transparent cluster key which must be located at the start of the key of all logical cluster tables to be included in the cluster. As well, a cluster contains a long field (VARDATA), which contains the
data of the cluster tables for this key. If the data does not fit into a field, continuation records are created.
Field Type Description
CLKEY1 CHAR(*) First key fields
CLKEY2 CHAR(*) Second key field
CLKEYN CHAR(*) nth key field
PAGENO INT2(5) Number of the next page
TIMESTMP CHAR(14) Time stamp
PAGELG INT2(5) Length of the VARDATA record returned
VARDATA RAW(*) Maximum length of the data section; varies according to database system
Working with Tables
The dictionary includes many functions for working with tables. There are five basic operations you can perform on tables: display, create, delete, modify, copy. Please do not confuse displaying a table with displaying the table entries (table contents). In order to display a table, it must previously exist; otherwise the system will display an error message in the status bar. For the following example, the table TABNA is used. To display this table, from the main dictionary screen, enter the table name in the Object name
input field with the radio button selected next to Tables. Then, click on the Display button at the bottom of the screen, or press the F7 function key, or, alternatively,
select Dictionary object Display from the menu.
In this screen, you can see table information such as
¨ Table type, shown next to the name of the object. In the example, it is a transparent table.
¨ Short text description.
¨ Name of the user who made the last change, and the date of the change.
¨ Master language.
¨ Table status. On the screen, you can see this table is saved and active.
¨ Development class. For information on development classes, refer to Chap. 6.
Delivery class, which sets the maintenance group for the table. It controls how tables will behave during client copy procedures, upgrades, and so forth.¨
Tab. Maint. Allowed flag, which indicates whether you can generate a screen for maintaining table entries.
¨Then, on the lower part of the screen, you can see the table fields with all associated characteristics such as:
¨ Field name.
¨ Key indicator. When set, this field is the primary key, or part of it.
¨ Data element.
¨ Basic data type.
¨ Length.
¨ Check table.
¨ Short text, describing the field.
Additional information about the table can be displayed by selecting the corresponding functions from the menu or directly from the application toolbar, such as keys, indexes, or technical settings
Regards
Sreeni

In "LOOP ... WHERE ..." the line type of the table must be statically defin

Hi All,
        I have written the code, for greater than (GJAHR) 2007 and restricted company codes ( table name = ZGLCCODE).
     Here I have written the following the code which is giving an error
In "LOOP ... WHERE ..." the line type of the table must be statically defin
ZGLCCODE Contains only restricted company codes.
Code is as follows
TABLES : ZGLCCODE.
DATA : LT_DATAPACKAGE TYPE TABLE OF DTFIGL_4.
DATA : LS_PACKAGE TYPE DTFIGL_4.
TYPES: BEGIN OF LS_TZGLCCODE,
       ZBUKRS type BUKRS,
        END OF LS_TZGLCCODE.
DATA : LT_ITZGLCCODE TYPE LS_TZGLCCODE OCCURS 0 WITH HEADER LINE.
DATA : LI_NUM TYPE I,
       LC_ZGJAHR TYPE BSEG-GJAHR VALUE '2007'.
SELECT ZBUKRS INTO TABLE LT_ITZGLCCODE FROM ZGLCCODE.
Note: "C_T_DATA" dynamic structure = "DTFIGL_4" structure
*- Remove from the DataSource Company Code -
LOOP AT C_T_DATA INTO LS_PACKAGE WHERE GJAHR GE '2007'.
READ TABLE LT_ITZGLCCODE WITH KEY ZBUKRS = LS_PACKAGE-BUKRS.
IF SY-SUBRC <> 0.
   APPEND LS_PACKAGE TO LT_DATAPACKAGE.
ENDIF.
CLEAR LS_PACKAGE.
ENDLOOP.
IF LT_DATAPACKAGE[] IS NOT INITIAL.
DESCRIBE TABLE LT_DATAPACKAGE LINES LI_NUM.
IF LI_NUM GT 0.
   REFRESH C_T_DATA.
   APPEND LINES OF LT_DATAPACKAGE TO C_T_DATA.
   REFRESH LT_DATAPACKAGE.
   FREE LT_DATAPACKAGE.
endif.
ELSE.
   REFRESH C_T_DATA.
ENDIF.
Please give me your valuable suggestions.
Thanks
Ganesh Reddy.

Hi Ganesh,
whatever you do, you can try like this:
1 - any code posted should be wrapped in \
then try something like this:
field-symbols:
<tabrec> type any,
<field>   type any.
sort ITZGLCCODE by bukrs.
LOOP AT C_T_DATA ASSIGNING <tabrec>.
ASSIGN component 'GJAHR' of structure <tabrec> to <field>.
check <field> <= 2007.
ASSIGN component 'BUKRS' of structure <tabrec> to <field>.
READ TABLE LT_ITZGLCCODE WITH KEY ZBUKRS = <field>
    BINARY SEARCH TRANSPORTING NO FIELDS. "speed up the volume.
IF SY-SUBRC 0.
    MOVE-CORRESPONDING <tabrec> to LS_PACKAGE.
    APPEND LS_PACKAGE TO LT_DATAPACKAGE.
ENDIF.
ENDLOOP.
Regards,
Clemens

Loading type in repository tables

Similar Messages

Maybe you are looking for