Setuptable

Why We Use SETUP table instead of base table in  LO-COCKPIT?
Please search the forum
Edited by: Pravender on Dec 27, 2010 5:14 PM

Hi ,
It is an interface btn r/3 and bi for extraction.
We cannot extract data into bi from Application tables directly.
when any user do posting that particualr will sit in application tables -- V1 update
After that this data used to sit in Setup tables --- V2 update.
Hope it helps.
Regards,
Ramnaresh.

Similar Messages

  • Setuptables in r/3

    Hi,
    Wht will be there in setuptables? extract structure or data??

    Hi,
    Please note that you can find a lot of information in the internet for setup tables which you can go through.
    Setup tables are application specific tables in the R/3 side to facilitate the LO data extraction.
    These can be filled to load the application specific data (History data) as a full load to the BW system.
    For example if you want to load the purchasing related data fill the setup table for 02 application so that the datasources will pick the data from that setup table on a full load infopackage run.
    Delta is handled seperately.
    The setup tables are the cluster tables to achieve full load in LO extraction.
    Thanks,
    Vishnu

  • NO Setuptable In Generic

    Hi,
       Can u explain me why there is no setuptable in Generic extraction. Please explain with example.
    TMS

    Hi,
    Adding to what is said above.
    Setup tables
    Setup tables hold historical data. Setup tables are based on the concept of Cluster tables means the data will be stored in a big table in database layer and it can be viewed in multiple smaller tables in application layer.
    Before doing Full or Init we have to do statistical setup. When we run statistical setup tables will be filled with the data, normally historical data, the data goes from database tables to Setup table. If you run the full or Init in BW then the data will be extracted from the setup tables. If you run the Delta then it will fetch from the delta queue. We use setup tables while we are doing Repair full request also. Repair full is nothing but extraction the historical data without disturbing the delta loads.
    Before running Statistical setup its good practice to delete setup tables’ contents to avoid data redundancy.
    The reason of using Set up table is that the SAP doesn't permit the extraction structure tables to access the database tables directly like. Rather than getting the data directly from the source tables (EKPO, MARC, VBRP, VBRK), the data is stored in Set up tables, which you can use for update to BW. After that all transaction data is posted to the delta queues in the source system. After a successful full upload you can delete the setup tables.
    Only after this step (initialization) any modification will be available as delta, following the schema explained before. In OLTP (R/3) the info packages retrieve data from the setup tables (and no postings have to be in the meanwhile, otherwise there would be some data loss!), which are assigned to the extract structures.
    You fill these tables using special setup transactions in OLTP (OLI*BW).
    For each extract structure, one setup table with the name of the extract structure and 'SETUP' as a suffix exists.
    for sales order setup tables will be like this
    for header : mc11va0hdrsetup
    for item level : mc11va0itmsetup
    for schedule line : mc11va0sclsetup
    u can view the data of setup tables in se11 or se16.
    Check this blogs from Roberto for Logistics Extraction:
    /people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
    /people/sap.user72/blog/2004/12/23/logistic-cockpit-delta-mechanism--episode-two-v3-update-when-some-problems-can-occur
    /people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
    /people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it
    /people/sap.user72/blog/2005/04/19/logistic-cockpit-a-new-deal-overshadowed-by-the-old-fashioned-lis
    These blogs will explain what, why and when of setup tables with beautiful screenshots.
    Generic extraction
    Usage:
    1. When the standard extractors are not supporting the extraction what you need. If SAP does not have a standard extractor for your need to get data from R3, you would have to go for generic extractor.
    2. If you create a custom object say by combining certain base tables in R3 say custom tables ZTAB1 and ZTAB2. These two tables are not SAP provided tables and there will not be any standard extractors. So cases like this you will have to go for generic extractors.
    Thanks,
    JituK

  • Setuptables

    hi frnds,
    i have one doubt ,
    why only LO maintains setuptables where other extractor doesn't maintain setuptables wt is main reason of setting setup tables in LO pls tell me in detail
    thanks & regards
    rashmi

    Hi Rashmi,
    The Logistics extraction and other extractions like FI, and COPA have a different extraction technology.
       In LO extraction, the setup reads the dataset that you want to process such as, customer orders with the application tables VBAK, VBAP.. and fill the relevant communication structures with data. The data is stored in cluster tables from where it is read when the initialization is run.
    Where as the other extractions like FI,CO-PA.. Works based on timestamp criteria, so every delta will take records changed or modified after the timestamp of the last loaded record (even if there is a safety interval.
    Also One of the main diffences is that the CO/FI data sources are "pull based", meaning, that the delta mechanism is based on a time stamp in the source table and data is pulled from these tables into the RSA7 queue. The LIS* data sources are "push" based meaning, that the delta mechanism is based on a intermediary que to which the delta records are pushed on time of transaction. From the intermediary the deltarecords are transferred to RSA7 queue. This is done by a R/3 sheduled job independent of BW exstractions.
    Hope it helps.
    Assign points if useful.
    Regards,
    Srikanth.
    Message was edited by: Srikanth Kanuri

  • Locockpit setuptable issue.

    Hi,
    I have to load 3yrs data for these data source 2lis_02_HDR,ACC,ITM . but user is not agreeing the down time for loading the these datasource to bw system. i gone through  some of documents like first load init without data transfer and followed by full repair load and deltas going to delta queue . shaill i go head in this procedure is there .Can any one suggest me on this issue.
    Regards
    RK

    hi,
    the extractor 2LIS_02_HDR has delta type - ABR i.e. this data source extracts the with After , before and reverse image.
    In your case if you are extracting data from this data source to DSO and then cube, then you can do as mentioned do a new init w/o data transfer, do full repair and then delta. this will not corrupt data as the DSO will have KF in overwrite mode and even if the PO numbers are extracted twice (in full repair and delta) the final snapshot will still match with R/3 system.
    Downtime is needed in the setup of extractors which are sending additive delta and the same record cannot be a part of setup table and delta, in your case it is not sending additive so no worries.
    regards,
    Arvind.

  • Serialized v3 update and setuptables

    i have 2 questions regarding LO extraction
    <b>Question 1.</b>
    while going thru the Lo cockpit step by step
    i found there is a certain point where we select serialized v3 update for an initilize delta load. As per  my knowledge, i read that serialised v3 is not used any more and is replaced by direct,queued and unserialized v3 update prcocess. if i am wrong where can we find the option to select serialized v3 update in LO cokcpit.
    <b>Question 2</b>
    when i tried to delete the setup table , the message shown Setup table deleted but i can see data for the same module in RSA3 after the process...hows is it possible.
    i appreciate if anyone can  reply me and points will be assigned for suitable answers..
    thanks and regards
    Abhilash Muraleedharan

    Abhilash,
    Follow the following steps
    Q1. In transaction LBWG there is an option to change the V3 delta to "Direct Delta". This should solve the problem. Make sure that the Queue is empty or else you willl not be able to change
    Q2. Make sure that you are selecting the right application hen you delete the data. Follow the follwing steps for filling the setup tables and seeing data in RSA3
    Run T-code MCNB for 2LIS_03_BX  setup
    Run SETUP for 2LIS_03_BF AND 2LIS_03_UM using TCodes OLI1BW and OLIZBW respectively.
    Thanks.

  • FILLING SETUPTABLES  PROBLEM

    intially  i have deleted  setup tables  at  LBWG  FOR  11  SD SALES...
    THEN  SBIW> setting for application data source>> logistics>> managing extract structures>> initilization>>filling in setup tables>> application specific  setup of  statistical data>> sd  sales order  perform setup>>
    and  i have  given  name of the run ZRUN (CHECKED  BOX  NEW RUN)
    GIVEN  TERMINATION  DATA AND  TIME....
    AFTER  EXECUTING
    IT ASKED START PROCESSING...
    PROCESSED  WITH IT..
    AFTER SOME  TIME  I SEE  SAME  SCREEN....
    WHEN I WENT  TO RSA3 AND  CHECKED  DATASOURCE  COULD NOT ABLE  TO  ANY RECORDS  IT SAYS  ZERO RECORDS 
    EVEN I  HAVE CHECKED  LBWQ AND  RSA7 AND  DELTED.. IF THERE ARE ANY  QUEUES....
    PLEASE REPLY
    WILL  REWARD  FULL POINTS...

    HI Guru,
    Go to transaction LBWE and make sure the update mode for the corresponding DataSource is serialized V3 update.
    Now for the delta records go to LBWE in R/3 and change the update mode for the corresponding DataSource to Direct/Queue delta. By doing this record will bypass SM13 and directly go to RSA7. Go to transaction code RSA7 there you can see green light # Once the new records are added immediately you can see the record in RSA7.
    hope this helps............

  • Setuptable MC04P_0COMSETUP empty

    Hello everybody,
    I’m tying to use the extractor 2LIS_04_P_COMP, but I am not able to fill the setup table 
    MC04P_0COMSETUP.
    I proceed as follow:
    1.     Deleting of the setup structures: lbwg -> Application 04. The setup table MC04P_0COMSETUP is empty and the extractor 2LIS_04_P_COMP run from the rsa3 returns no rows.
    2.     Run of the program oli4bw. It takes a lot of time for finishing this program but as result there are still no rows in the MC04P_0COMSETUP.
    I run the oli4bw without restriction. I’ve tried all the possibilities for the field Detailed (empty, C, F,B). And it is not working. The  MC04P_0COMSETUP is still empty.
    Could anyone help me?
    Thnx in advance.
    Pawel

    Hi Hari,
    thnx 4 your answer.
    regarding sm37 log: it does not say a lot for me.
    There were 3 lines. The first with the information about starting the task. The second about starting step number 1 (program  RMCFNEUA for user pawel). The third with the information about finishing the task. It took about 2 minutes to finish the program.
    What do you mean by setup log?
    What are the source tables for this application? I've checked, wheter there is data available via the user interface. Not exactly me, but a colleague of mine who is familiar with PP/MM. And according to him, there is data in the system.
    BR,
    Pawel

  • Regarding filling of setupt ables for inventory

    HI All..
    I ahjve to delete and refill teh set up tables fr stock.
    In my cube I chekc n find there the last opening balance req 2lis_03_bx package was scheduled long back
    after thata regular deltas are running.
    now whn i m filling am I suppose to fill the opening DS first ie 2lis_03_bx or can i directly fill the 2lis_02_bf(delta) DS

    check set upt ables rsa3...
    delete lbwg
    fillin sbiw, search for fill set up tables... searhcing would be your best option if you dont fnind it reply back and i;ll tell you how to get there... then again check in rsa3... you should find up dated record number, replicate in bw,,,
    lbwq for delta maintanance... qrfc monitor outbound query....
    rsa7- bw delta queue... hv fun
    award points

  • Problem while filling the Setup Table for the DS 2LIS_02_SCL.

    Hi All,
    When I am trying to fill the Setup table for the DataSource 2LIS_02_SCL and only for one specific Purchase Order, it is showing me a message like
    u201CDataSource 2LIS_02_ITM contains data still to be transferredu201D
    I have deleted the Setup Table and I want to delete the entries from SM13, but I do not have Authorization.
    Also, here I am trying to fill the Setup Table for 2LIS_02_SCL and not for 2LIS_02_ITM, but the message displayed above is showing as 2LIS_02_ITM DataSource. I think the Setup Table will be same for both the DataSources.
    Waiting for your valuable inputs.
    Thanks in Advance.

    Hi,
    When you want to fill the setup tables first you need to delete setup tables to avoid the duplicate entires in setup tables ( you can delete the setup tables by using t.code LBWG with application no is 02)
    In your case, the data souce is 2LIS_02_SCL for purchasing.
    when you want to delete the setup tables by using t.code LBWG with 02 application no it will delete all the purchasing related data from all the data sources like
    2LIS_02_SCL
    2LIS_02_ITM
    Before the deletion of setup tables you need to clear the delta Queues and stop the V3 jobs, which loads the data to Delta Queues (RSA7) and Update tables(LBWQ).
    you need to run the V3  jobs manually by using LBWE > Job control > and schedule the jobs until the delta queues will get 0 records. that means no data will be available in RSA7 and LBWQ
    go to SM37 to see the jobs LIS-BW-VB_APPLICATION_02,
    once the delta queues gets 0 records by running V3 Jobs manullay.
    Then remove the released state jobs > remove from schedule means delete the jobs in LBWE > Go to job control > you can delete the released jobs.
    Becuase No postings to be done in application tables, while running setuptable filling you should take some down time to fill the setup tables.( OLI*BW)  *=Application number.
    Once you clear the Queues and delete the v3 jobs, then you need to fill the setup tables after deletion of setup tables.
    once you fill the setup tables , by running intialization to BW side the delta Queue is formed for the data source in R3 side
    Now the postings can be done in R3 side, so you need schedule back the V3 jobs, which you already delted from LBWE to load the data from application tables to RSA7 or LBWQ.
    I hope this may help yoou.
    Regards.
    Rambabu
    Edited by: Rambabu velanati on Jun 9, 2010 4:41 PM
    Edited by: Rambabu velanati on Jun 9, 2010 4:52 PM

  • Filling of setup table

    Hi,
    I got the error message while filling the data in setup table.
    i got message is follows in Joblog.
    Program terminated, time limit exceeded: 3,795,659 document item(s) updated
    Message no. M2227
    Diagnosis
    The setup run exceeded the specified termination time.
    System response
    The run was terminated.
    My doubt is if i check the option Rerun and i will give my jobname.
    it will start the job where the job was terminated its correct.
    if they wont provide time to fill the setuptable, i mean they asking me, is it ok to do 2 users in transaction after 9 P.M., the time in which iam going to fill the setuptable.
    I told to our client, no should lock the user. document mismatching will happen.
    Is it any other way is there user to allow transaction the time in which iam filling the setuptable..

    Hi,
    These are related links:
    Time Limit Exceeded Error Encountered
    Termination message for an attribute change run "Time limit exceeded."
    Extraction Error : Time limit exceeded
    XI :  How to Re-Process failed XI Messages Automatically

  • Question regarding deltas and filling of setup tables

    Hello Friends,
    We are using the Sales Order Item Datasource 2LIS_11_VAITM. We have transported it to BI Production. We have initialized the delta and the deltas are running for the past 3-4 months.
    Now we had a new requirement which was getting satisfied by the Sales Order Header and Sales Order Header Status DataSources, 2LIS_11_VAHDR & 2LIS_11_VASTH respectively.
    Now we wan to transfer both these (header & header status) DataSources to BI Procution. My question is:
    1) Do we have to refill the setup tables again in R/3 for the Sales (11) application?
    2) Do we have to reload the entire Sales data again from scratch.
    3) Is there any way to transport the 2 new DataSources to BI Production and without disturbing the already running deltas of Sales Order Item Datasource?
    Regards,
    Prem.

    Hi,
    1) Do we have to refill the setup tables again in R/3 for the Sales (11) application?.
    Yes you need to refill the setuptables, because if you want to load deltas, you need to do Init then deltas, other wise first time when you are filled setup tables, (first load init with the existing data in setuptables) from that day to till date you can do full then you can set delta.
    It is better and good to fill setup tables and load.
    2) Do we have to reload the entire Sales data again from scratch.
    Any way you need down time to load the other 2 datasources, and also for 11 application you are filling setuptables.So for perfectness it is better to load from first.
    3) Is there any way to transport the 2 new DataSources to BI Production and without disturbing the already running deltas of Sales Order Item Datasource?
    If you transport the new datasources then delta won't distrub in BW. If you did any changes to DataSource and trying to transport it to production then it will give error, because LBWQ and RSA7 will have data so first you need to clear it and then transport it.
    Thanks
    Reddy

  • Two phase commit and bean managed transactions

    To all the Transaction GURUS!
              Hi guys (-and gals).
              I've been doing J2EE for quite a while, but today was my first at
              XA-Transactions and Bean Managed Transactions.
              Why am I doing this?
              ====================
              Well I have to be able to controll the transactionalbehaviour of my
              bean
              during runtime, since some bean calls would cause a transactional
              overflow due to the stress they would cause to the system, whereas
              smaller bean calls need to run in one transaction.
              -> Therefore I need Bean Managed Transactions
              Since the bean does a call on two Database Connections it has to use a
              XA-Transaction.
              -> Therefore I need XA-Transactions.
              Abstract
              ========
              - I just can't get a User TransAction into the right Status it stays
              in 'STATUS_NO_TRANSACTION' all the time
              - Therefore the SQL Commands can be comitted 'java.sql.SQLException:
              Does not support SQL execution with no global transaction'
              - Therefore I can't do a rollback 'java.lang.IllegalStateException:
              Transaction does not exist'
              - Therefore I wrote this mail.
              I don't want to be a smart-"ass" writing such a detailed and indepth
              mail. I just would like to show that I tried, and would like to have
              some replies from you guys.
              Below are my configurations, code and logfiles.
              Thanx for taking your time and hope that the other people may learn
              something as well.
              cu
              Stefan
              Scenario
              ========
              used Software
              Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
              Oracle 8.1.6 using the API-Version 8
              I configured the system as follows:
              (ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
              excerpt from:
              config.xml
              <JDBCConnectionPool CapacityIncrement="5"
              DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
              LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
              Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
              RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
              <!-- Since this is our Main Datasource I would not like to use a XA
              Transaction due to performance Issues
              and the TxDataSource:
              -->
              <JDBCTxDataSource EnableTwoPhaseCommit="true"
              JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
              PoolName="oraclePool" Targets="fbsserver"/>
              <!-- no comment required -I hope.
              Next comes the "special" Pool
              -->
              <JDBCConnectionPool CapacityIncrement="5"
              DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
              LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
              Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
              RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              TestTableName="Users" SupportsLocalTransaction="true"/>
              <!-- Well since there can only be one none XARessourceManager involved
              in a 2PC
              (keyword: Two Phase Commit) I will have to use a XACapable Driver for
              the other
              Datasource. Due to all the bugs in the oracle.xxx driver. I'll be
              using the jdriver for oci.
              I activated 'SupportsLocalTransaction' hoping it would solve my
              problem - without effect. I just left in there now, since it made
              sense me. Not?
              Again the TxDataSource:
              -->
              <JDBCTxDataSource EnableTwoPhaseCommit="true"
              JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
              Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
              <!-- The System starts right up and can locate the test tables and
              everything. So I think all of this stuff is working here -->
              ejb-jar.xml
              <ejb-jar>
                   <enterprise-beans>
                        <session>
                             <ejb-name>TPCTestBean</ejb-name>
              <home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
              <remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
              <ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
                             <session-type>Stateless</session-type>
                             <transaction-type>Bean</transaction-type>
                        </session>
                   </enterprise-beans>
                   <assembly-descriptor/>
              </ejb-jar>
              <!-- Originally I had the assembly-descriptor full of transaction
              requirements. I thought since
              the bean is handling all of the transaction stuff itself, it might get
              confused by the 'container-transaction'
              properties, and deleted them. Do I need them anyway?-->
              weblogic-ejb-jar.xml
              <weblogic-ejb-jar>
                   <weblogic-enterprise-bean>
                        <ejb-name>TPCTestBean</ejb-name>
                        <stateless-session-descriptor/>
                        <jndi-name>finstral/ejb/test_tpc</jndi-name>
                   </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              <!-- Nothing I have to explain here -->
              BeanCode (from the implementingBeanClass:
              'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
              public void setupTables() throws RemoteException
              UserTransaction tx = getTransaction();
              //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
              some errorhandling
              log.info("Die Transaktion vor den Connections: "+tx.toString());
              //Sorry bout the German. You should get the Message though.
              log.info("Der Transaktionsstatus vor den Connections:
              "+transactionStatus(tx));
              Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
              //gets a Connection via a DataSourceName from the JNDI tree
              Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
              log.info("Die frische Connection conSecurity: "+conSecurity);
              log.info("Die frische Connection conContent: "+conContent);
              tearDownTable(conSecurity);
              //Does nothing special
              tearDownTable(conContent);
              log.info("Die Transaktion nach dem Teardown: "+tx.toString());
              log.info("Der Transaktionsstatus nach dem Teardown:
              "+transactionStatus(tx));
              Statement stmt = null;
              try
              stmt = conSecurity.createStatement();
              //Well its getting interesting now.....
              log.info("Die Transaktion vor dem createtable: "+tx.toString());
              log.info("Der Transaktionsstatus vor dem createtable:
              "+transactionStatus(tx));
              log.info("Die Connection conSecurity vor dem createtable:
              "+conSecurity);
              log.info("Die Connection conContent vor dem createtable:
              "+conContent);
              stmt.executeUpdate(CREATE_TABLE);
              //above is the row 91 -> throws: 'java.sql.SQLException: Does
              not support SQL execution with no global transaction'
              stmt.close();
              stmt = conContent.createStatement();
              stmt.executeUpdate(CREATE_TABLE);
              stmt.close();
              commitTransaction(tx);
              catch (SQLException sqle)
              log.error("Konnte kein table init machen", sqle);
              rollbackTransaction(tx);
              //The Code for this method is below
              throw new EJBException(sqle);
              finally
              closeConnection(conSecurity);
              closeConnection(conContent);
              protected void rollbackTransaction(UserTransaction tx)
              log.info("Der Transaktionsstatus vor dem Rollback:
              "+transactionStatus(tx));
              log.info("Die Transaktion vor dem Rollback: "+tx.toString());
              try
              tx.rollback();
              //above is row 200 -> throws: 'java.lang.IllegalStateException:
              Transaction does not exist'
              log.info("Der Transaktionsstatus nach dem Rollback:
              "+transactionStatus(tx));
              log.info("Die Transaktion nach dem Rollback: "+tx.toString());
              catch (Exception e)
              log.error("Konnte die Transaktion nicht backrollen.", e);
              throw new EJBException(e);
              Log Excerpt
              ===========
              INFO setupTables() (66) - Die Transaktion vor den Connections:
              [email protected]
              INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
              STATUS_NO_TRANSACTION
              INFO setupTables() (72) - Die frische Connection conSecurity:
              weblogic.jdbc.rmi.SerialConnection@7c6daa
              INFO setupTables() (73) - Die frische Connection conContent:
              weblogic.jdbc.rmi.SerialConnection@3b425
              INFO setupTables() (78) - Die Transaktion nach dem Teardown:
              [email protected]
              INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
              STATUS_NO_TRANSACTION
              INFO setupTables() (86) - Die Transaktion vor dem createtable:
              [email protected]
              INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
              STATUS_NO_TRANSACTION
              INFO setupTables() (88) - Die Connection conSecurity vor dem
              createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
              INFO setupTables() (89) - Die Connection conContent vor dem
              createtable: weblogic.jdbc.rmi.SerialConnection@3b425
              ERROR setupTables() (101) - Konnte kein table init machen
              java.sql.SQLException: Does not support SQL execution with no global
              transaction
                   at
              weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
                   at
              weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
                   at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
                   at
              weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.jav
              a:42)
                   at
              weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
              a:91)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
              Impl.java:130)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
              anEOImpl.java:64)
                   at
              de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
              mmitUnitTest.java:51)
                   at
              org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
              tCase.java:297)
                   at
              org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
              tTestCaller.java:148)
                   at
              org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
              ler.java:199)
                   at
              org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
              tRedirector.java:149)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
                   at
              weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
              java:213)
                   at
              weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
              etContext.java:1265)
                   at
              weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
              java:1631)
                   at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
                   at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
              Rollback: STATUS_NO_TRANSACTION
              INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
              [email protected]
              ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
              backrollen.
              java.lang.IllegalStateException: Transaction does not exist
                   at
              weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
              nManagerImpl.java:228)
                   at
              weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
              nManagerImpl.java:222)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TPC
              Bean.java:200)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
              a:102)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
              Impl.java:130)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
              anEOImpl.java:64)
                   at
              de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
              mmitUnitTest.java:51)
                   at
              org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
              tCase.java:297)
                   at
              org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
              tTestCaller.java:148)
                   at
              org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
              ler.java:199)
                   at
              org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
              tRedirector.java:149)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
                   at
              weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
              java:213)
                   at
              weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
              etContext.java:1265)
                   at
              weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
              java:1631)
                   at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
                   at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              CONCLUSION
              ==========
              I'm going nuts.
              I just don't get it.
              The transaction is the same. I don't change the Connection. I start
              the Transaction at the beginning before I do anything!
              Please guys help me out.
              Thx alot.
              Stefan "it's three o'clock in the morning, my girlfriend left me, and
              my only friend is that stupid linux pinguine" Siprell
              Software-Development
              <<<<<<<<<<<<<<<<<<<<<<<<<<<
              <sitewaerts> GmbH
              Hebelstraße 15
              D-76131 Karlsruhe
              Tel: +49 (721) 920 918 22
              Fax: +49 (721) 920 918 29
              http://www.sitewaerts.de
              >>>>>>>>>>>>>>>>>>>>>>>>>>>
              

    Hi Priscilla
              (did you ever see the movie ? :-))
              Well I moved away from the idea of using bean managed transaction. I'll
              be using Container Managed Transactions. To modify the
              transactionalbehaviour I'll write proxymethods which have certain
              different containermanaged transaction properties, but which all call
              the same private methods.
              But it works! Here is my experience:
              - I was doing a DDL statement: I was trying to create new Tables, which
              is a definite "no-go"
              - pay careful attention to:
              http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051405
                        and
              http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051741
              and use these Settings for the Pool, don't ask me why, but it took me
              hours to find it out by myself:
                   <JDBCConnectionPool CapacityIncrement="5"
              DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
              LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
              Properties="user=xxx; password=xxx; server=xxx.xxx.xxx"
              RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              TestTableName="Users" SupportsLocalTransaction="true"/>
              where as the server (shown as: xxx.xxx.xxx) is the TNS Name of the
              Oracle Driver.
              It works great.
              Another thing you guys might want to do is write a simple StatelessSB
              which does JDBC calls and two different database Connections.
              Then write a UnitTest which calls this bean a couple hundred times (with
              the same transaction). Have one test do clean writes, and another which
              causes some SQL-Exception (too long Data Columns, or likewise).
              Always count the entries and see if everything worked out. We're using
              this SetupConstruction to test new combinations of AS(sorry Priscilla) /
              Database / Db-Drivers to have a "standard test".
              I know my two cents were uncalled for, but it might save you some
              time.....
              thanx for your help
              Stefan
              -----Ursprüngliche Nachricht-----
              Von: Priscilla Fung [mailto:[email protected]]
              Bereitgestellt: Donnerstag, 2. August 2001 21:42
              Bereitgestellt in: transaction
              Unterhaltung: Two phase commit and bean managed transactions
              Betreff: Re: Two phase commit and bean managed transactions
              Hi Stefan,
              Looks like you have not actually begun a transaction by calling
              UserTransaction.begin(),
              so your setupTables method is really executing with no transaction
              context.
              Priscilla
              Stefan Siprell <[email protected]> wrote:
              >To all the Transaction GURUS!
              >
              >Hi guys (-and gals).
              >I've been doing J2EE for quite a while, but today was my first at
              >XA-Transactions and Bean Managed Transactions.
              >
              >Why am I doing this?
              >====================
              >Well I have to be able to controll the transactionalbehaviour of my
              >bean
              >during runtime, since some bean calls would cause a transactional
              >overflow due to the stress they would cause to the system, whereas
              >smaller bean calls need to run in one transaction.
              >-> Therefore I need Bean Managed Transactions
              >Since the bean does a call on two Database Connections it has to use
              >a
              >XA-Transaction.
              >-> Therefore I need XA-Transactions.
              >
              >Abstract
              >========
              >- I just can't get a User TransAction into the right Status it stays
              >in 'STATUS_NO_TRANSACTION' all the time
              >- Therefore the SQL Commands can be comitted 'java.sql.SQLException:
              >Does not support SQL execution with no global transaction'
              >- Therefore I can't do a rollback 'java.lang.IllegalStateException:
              >Transaction does not exist'
              >- Therefore I wrote this mail.
              >
              >I don't want to be a smart-"ass" writing such a detailed and indepth
              >mail. I just would like to show that I tried, and would like to have
              >some replies from you guys.
              >
              >Below are my configurations, code and logfiles.
              >
              >Thanx for taking your time and hope that the other people may learn
              >something as well.
              >
              >cu
              >
              >Stefan
              >
              >
              >Scenario
              >========
              >
              >used Software
              >-------------
              >Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
              >Oracle 8.1.6 using the API-Version 8
              >
              >
              >I configured the system as follows:
              >(ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
              >excerpt from:
              >
              >config.xml
              >----------
              ><JDBCConnectionPool CapacityIncrement="5"
              >DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
              >LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
              >Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
              >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              >TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
              >
              ><!-- Since this is our Main Datasource I would not like to use a XA
              >Transaction due to performance Issues
              >and the TxDataSource:
              >-->
              >
              ><JDBCTxDataSource EnableTwoPhaseCommit="true"
              >JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
              >PoolName="oraclePool" Targets="fbsserver"/>
              >
              ><!-- no comment required -I hope.
              >Next comes the "special" Pool
              >-->
              >
              ><JDBCConnectionPool CapacityIncrement="5"
              >DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
              >LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
              >Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
              >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              >TestTableName="Users" SupportsLocalTransaction="true"/>
              >
              ><!-- Well since there can only be one none XARessourceManager involved
              >in a 2PC
              >(keyword: Two Phase Commit) I will have to use a XACapable Driver for
              >the other
              >Datasource. Due to all the bugs in the oracle.xxx driver. I'll be
              >using the jdriver for oci.
              >I activated 'SupportsLocalTransaction' hoping it would solve my
              >problem - without effect. I just left in there now, since it made
              >sense me. Not?
              >Again the TxDataSource:
              >-->
              >
              ><JDBCTxDataSource EnableTwoPhaseCommit="true"
              >JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
              >Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
              >
              ><!-- The System starts right up and can locate the test tables and
              >everything. So I think all of this stuff is working here -->
              >
              >
              >
              >ejb-jar.xml
              >-----------
              ><ejb-jar>
              >     <enterprise-beans>
              >          <session>
              >               <ejb-name>TPCTestBean</ejb-name>
              >     
              ><home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
              >     
              ><remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
              >     
              ><ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
              >               <session-type>Stateless</session-type>
              >               <transaction-type>Bean</transaction-type>
              >          </session>
              >     </enterprise-beans>
              >     <assembly-descriptor/>
              ></ejb-jar>
              >
              ><!-- Originally I had the assembly-descriptor full of transaction
              >requirements. I thought since
              >the bean is handling all of the transaction stuff itself, it might get
              >confused by the 'container-transaction'
              >properties, and deleted them. Do I need them anyway?-->
              >
              >weblogic-ejb-jar.xml
              >--------------------
              ><weblogic-ejb-jar>
              >     <weblogic-enterprise-bean>
              >          <ejb-name>TPCTestBean</ejb-name>
              >          <stateless-session-descriptor/>
              >          <jndi-name>finstral/ejb/test_tpc</jndi-name>
              >     </weblogic-enterprise-bean>
              ></weblogic-ejb-jar>
              >
              ><!-- Nothing I have to explain here -->
              >
              >BeanCode (from the implementingBeanClass:
              >'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
              >-----------------------------------------------------------------------
              >---------------------
              >
              > public void setupTables() throws RemoteException
              > {
              > UserTransaction tx = getTransaction();
              > //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
              >some errorhandling
              >
              > log.info("Die Transaktion vor den Connections: "+tx.toString());
              > //Sorry bout the German. You should get the Message though.
              > log.info("Der Transaktionsstatus vor den Connections:
              >"+transactionStatus(tx));
              >
              > Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
              > //gets a Connection via a DataSourceName from the JNDI tree
              > Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
              >
              > log.info("Die frische Connection conSecurity: "+conSecurity);
              > log.info("Die frische Connection conContent: "+conContent);
              >
              > tearDownTable(conSecurity);
              > //Does nothing special
              > tearDownTable(conContent);
              >
              > log.info("Die Transaktion nach dem Teardown: "+tx.toString());
              > log.info("Der Transaktionsstatus nach dem Teardown:
              >"+transactionStatus(tx));
              >
              > Statement stmt = null;
              > try
              > {
              > stmt = conSecurity.createStatement();
              > //Well its getting interesting now.....
              >
              > log.info("Die Transaktion vor dem createtable: "+tx.toString());
              > log.info("Der Transaktionsstatus vor dem createtable:
              >"+transactionStatus(tx));
              > log.info("Die Connection conSecurity vor dem createtable:
              >"+conSecurity);
              > log.info("Die Connection conContent vor dem createtable:
              >"+conContent);
              >
              > stmt.executeUpdate(CREATE_TABLE);
              > //above is the row 91 -> throws: 'java.sql.SQLException: Does
              >not support SQL execution with no global transaction'
              >
              > stmt.close();
              >
              > stmt = conContent.createStatement();
              > stmt.executeUpdate(CREATE_TABLE);
              > stmt.close();
              > commitTransaction(tx);
              > }
              > catch (SQLException sqle)
              > {
              > log.error("Konnte kein table init machen", sqle);
              > rollbackTransaction(tx);
              > //The Code for this method is below
              > throw new EJBException(sqle);
              > }
              > finally
              > {
              > closeConnection(conSecurity);
              > closeConnection(conContent);
              > }
              > }
              >
              > protected void rollbackTransaction(UserTransaction tx)
              > {
              > log.info("Der Transaktionsstatus vor dem Rollback:
              >"+transactionStatus(tx));
              > log.info("Die Transaktion vor dem Rollback: "+tx.toString());
              > try
              > {
              > tx.rollback();
              > //above is row 200 -> throws: 'java.lang.IllegalStateException:
              >Transaction does not exist'
              > log.info("Der Transaktionsstatus nach dem Rollback:
              >"+transactionStatus(tx));
              > log.info("Die Transaktion nach dem Rollback: "+tx.toString());
              > }
              > catch (Exception e)
              > {
              > log.error("Konnte die Transaktion nicht backrollen.", e);
              > throw new EJBException(e);
              > }
              > }
              >
              >Log Excerpt
              >===========
              >INFO setupTables() (66) - Die Transaktion vor den Connections:
              >[email protected]
              >INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
              >STATUS_NO_TRANSACTION
              >INFO setupTables() (72) - Die frische Connection conSecurity:
              >weblogic.jdbc.rmi.SerialConnection@7c6daa
              >INFO setupTables() (73) - Die frische Connection conContent:
              >weblogic.jdbc.rmi.SerialConnection@3b425
              >INFO setupTables() (78) - Die Transaktion nach dem Teardown:
              >[email protected]
              >INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
              >STATUS_NO_TRANSACTION
              >INFO setupTables() (86) - Die Transaktion vor dem createtable:
              >[email protected]
              >INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
              >STATUS_NO_TRANSACTION
              >INFO setupTables() (88) - Die Connection conSecurity vor dem
              >createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
              >INFO setupTables() (89) - Die Connection conContent vor dem
              >createtable: weblogic.jdbc.rmi.SerialConnection@3b425
              >ERROR setupTables() (101) - Konnte kein table init machen
              >java.sql.SQLException: Does not support SQL execution with no global
              >transaction
              >     at
              >weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
              >     at
              >weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
              >     at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
              >     at
              >weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.ja
              v
              >a:42)
              >     at
              >weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
              v
              >a:91)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
              n
              >Impl.java:130)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
              e
              >anEOImpl.java:64)
              >     at
              >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
              o
              >mmitUnitTest.java:51)
              >     at
              >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
              s
              >tCase.java:297)
              >     at
              >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
              e
              >tTestCaller.java:148)
              >     at
              >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
              l
              >ler.java:199)
              >     at
              >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
              s
              >tRedirector.java:149)
              >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
              >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
              >     at
              >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
              >java:213)
              >     at
              >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
              l
              >etContext.java:1265)
              >     at
              >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
              >java:1631)
              >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
              >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
              >Rollback: STATUS_NO_TRANSACTION
              >INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
              >[email protected]
              >ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
              >backrollen.
              >java.lang.IllegalStateException: Transaction does not exist
              >     at
              >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
              o
              >nManagerImpl.java:228)
              >     at
              >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
              o
              >nManagerImpl.java:222)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TP
              C
              >Bean.java:200)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
              v
              >a:102)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
              n
              >Impl.java:130)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
              e
              >anEOImpl.java:64)
              >     at
              >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
              o
              >mmitUnitTest.java:51)
              >     at
              >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
              s
              >tCase.java:297)
              >     at
              >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
              e
              >tTestCaller.java:148)
              >     at
              >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
              l
              >ler.java:199)
              >     at
              >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
              s
              >tRedirector.java:149)
              >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
              >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
              >     at
              >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
              >java:213)
              >     at
              >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
              l
              >etContext.java:1265)
              >     at
              >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
              >java:1631)
              >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
              >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >
              >
              >CONCLUSION
              >==========
              >I'm going nuts.
              >I just don't get it.
              >The transaction is the same. I don't change the Connection. I start
              >the Transaction at the beginning before I do anything!
              >Please guys help me out.
              >Thx alot.
              >
              >Stefan "it's three o'clock in the morning, my girlfriend left me, and
              >my only friend is that stupid linux pinguine" Siprell
              >Software-Development
              ><<<<<<<<<<<<<<<<<<<<<<<<<<<
              ><sitewaerts> GmbH
              >Hebelstraße 15
              >D-76131 Karlsruhe
              >
              >Tel: +49 (721) 920 918 22
              >Fax: +49 (721) 920 918 29
              >http://www.sitewaerts.de
              >>>>>>>>>>>>>>>>>>>>>>>>>>>>
              >
              >
              >
              

  • Data not loading /updating into cube 0lc_c03

    Dear Friends,
    I extracted data for three data sources i.e. 2lis_03_bx,
    2lis_03_bf,2lis_03_um i got data in BW PSA with out any
    error but that data is not updating in cube 0lc_c03
    i have done settings at r/3 at t.code mcnb,SBIW and I had make NDI flag active at t.code FIBF. do i need to right.
    at SBIW I have done like this settings: Inventory controlling
    1,Determine Industry sector I have selected Standard (core).
    2,Transaction key maintenance for SAP BW I have selected application MM and operat all i.e. 0,1,2,3,4,5,6........all of MM and saved
    3,Then stock initialization.
    and deleted setup table data for inventory controlling
    and after assigning keys I again loaded setuptable.
    I am geting data in r/3 rsa3 and in BW PSA with out errors for all three data sources but not geting in cube
    but at data source 2lis_03_um update rules there are few key figures with out green light i.e. 'x' but update rules are active please guide me do ineed to write
    any update rule level routines please guide me.
    please guide me how to get data into cube.
    Thanks in Advances
    rafeeq ahmed
    <b></b>

    Hi rafeeq,
    Are you using business content update rules or custom.
    check each rule seperately. do a simulation on the data load, if you feel the update rules are correct.
    Check if your validity table is maintained.
    hope it helps.
    kris

  • Urgent Entries for application 11 still exist in the extraction queue

    Hi All,
    In LBWE when i am trying to mainting structure its not allowing to add fields to ExtractStrucutre.
    Following is the error iam getting.
    Entries for application 11 still exist in the extraction queue ->
    I have set the Update to inactive and trying to add fields to Extract strucutre .
    Morover,
    I have already deleted setuptable entries for this application Component 11 and i checked in rsa3, no records are there.
    Regards,
    C.V.
    Message was edited by: P.C.V.

    PCV,
    Here are the steps. Make sure you do them when there is no posting going on.
    1) Using transaction SA38, execute program RMBWV311. This will send the data from the extraction queue to delta queue for application 11.
    2) Run your 2lis_11_***** info packages to bring the delta records into BW. Make sure to run these info packages twice because the delta is cleared on R/3 only if you run them twice. It is designed this way to accomodate the delta repetition functionality.
    Just to make sure, verify that you don't see any data in RSA7, LBWQ and if you use RSA3, the system should not extract any data.
    You should be able to change the extract structure now.
    Abdul

Maybe you are looking for