Update Mode in Copy Method

Hi all,
I found in our system, for "Copy" Method,  if the input type=periodic then only available update mode is "Delete All".
Is it standard? Is there any specific reason why they disable update mode="no modification"?
Thanks in advance.

Hi,
You should read sapnote 0000936590
Lot's of interesting remarks regarding the copy function
Regards,
Thibaud

Similar Messages

  • V1, V2, V3 update modes

    Hi,
    Can anyone tell me what are V1, V2, V3 update modes. Please tell me the difference between all the three. Are there any other update modes? How are the above different from - Direct Delta , Queued delta and unserialized v3 update methods?
    Am actually very confused with the above topics.
    It would be great if someone could explain in details.
    Thanks in advance,
    maddy

    Hi Maddy.
    V1 denotes time-critical updates used for updating the
    actual transaction tables.
    V2 denotes non-time-critical updates used for updating
    statistics tables related to the transaction tables.
    For instance, after a sales order entry transaction
    is completed, the corresponding sales order tables would be
    updated in V1 mode, and the corresponding statistics tables
    would be updated in V2 mode.
    V3 update mode(Uses delta queue technology) is similar
    to the V2 update mode. The main difference is that V2
    updates are always triggered by applications, while V3
    updates may be scheduled independently. Many extraction
    programs available for mySAP.com applications today use the
    delta queue technology to identify deltas.
    and also check this
    hi
    V1,V2,V3 updates
    v1, v2,and v3 updates
    V1, V2 and V3 updates in LO
    LO Cockpit contains a set of extract structures and enable extraction of logistics data to your SAP BI system via logistics DataSources.
    Check the following links
    /people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
    LOGISTIC COCKPIT DELTA MECHANISM - Episode two: V3 Update, when some problems can occur...
    LOGISTIC COCKPIT DELTA MECHANISM - Episode three: the new update methods
    LOGISTIC COCKPIT - WHEN YOU NEED MORE - First option: enhance it !
    LOGISTIC COCKPIT: a new deal overshadowed by the old-fashioned LIS ?
    Also check the step by step guide below.
    http://www.sap-img.com/business/lo-cockpit-step-by-step.htm
    thanks
    sreeni

  • Bridge cc expand to dual monitor mode when copying or deleting photos?

    why does bridge cc expand to dual monitor mode when copying or deleting photos?

    You say your running 10.5.6?  Why haven't you updated to 10.5.8?
    FWIW, I never had color issues under 10.5.X, however I have since upgrade to 10.6.
    See the thread I started in which Adobe responded:
    http://forums.adobe.com/thread/483359

  • Error Message: Change of update mode not possible due to open V3 update

    Hi Gurus,
    I got error message when i change update mode (LBWE) from V3 to Direct or Queued delta method.
    Error Message: Change of update mode not possible due to open V3 update
    Long text: You are not allowed to change the update mode for application 11 from V3 to another method. This is because there are still V3 update entries for update module MCEX_UPDATE_11 that have not been processed yet.
    Pls anyone give solution for this.
    Thanks
    Muthu

    Hi Sreeni,
    i did check in all the below Tcode as you adviced.
    1. Clear all record at SM13, LBWQ / SMQ1, Setup tables, RSA7 for particular datsasource or application..
    2. For LBWQ provide date range and delete not required records.
    I did not get the 3rd point " Need to clear in CLINTS of R/3 system" of your reply.
    what does that mean?
    I checked all the above tcodes and got the same message as no queue or data exists".
    I went SBIW tcode and activated my data source and try to change the Update mode but still it is throwing error message as "Change of update is not possible due to open V3"
    Please help me out.
    It will be very helpful for me if you could share steps or docs regarding this issue.
    Thanks,
    Shailaja

  • Unable to Change Update Mode

    Hi All,
    I'm  having this scenario, I want to change from unserialized V3 update to queue update but the following message appear, how do I go about it
    Change of update mode not possible due to open V3 update -> Long text
    Message no. MCEX 160
    Diagnosis
    You are not allowed to change the update mode for application 03 from V3 to another method. This is because there are still V3 update entries for update module MCEX_UPDATE_03 that have not been processed yet.
    Procedure
    Start the V3 update using the "Job Control" function in the customizing cockpit (transaction LBWE) or delete the update entries that are already incorrect. You can find these in the Update Overview.
    Tried clearing it for this particular datasource via RSA7 and SM13
    Thanks
    Zan

    1. Deschedule the V3 Job from Job Control.
    2. Run the V3 Job with immediate option.
    3. Check in LBWQ and SMQ1 the entries related to application 03 should be zero.
    4. Now clear the delta Queue and now RSA7 entries related to application 03 should be zero.
    Note: During all these steps no postings should occur at R/3 side.
    Now change the delta mode.
    Cheers,
    Neel.

  • Update mode for Infopackage

    Hi,
    i have a question about Infopackage to ask you. I would like to create an Infopackage for Delta-Init Load IN Update Mode. When i create an infopackage, why only Full load in Update Mode appears? There are no Update mode for Delta upload and Initialize delta Process vorhand. How can i let it appear?
    I extract data from CSV Flatfile.
    Thanks!

    if you want to load delta loads using Flat file.... first load the data till DSO1.. next you can load your 2nd and 3rd files as full loads to DSO, from DSO to cube do a INIT load you can find this option at info pack update tab, after doing this you can able to see Delta option at update tab, instead of selecting delta option here you can just copy your info pack and select delta option and do delta loads from now onwards. so in feature you can use the INIT info pack if any errors occurs. if data loaded to DSO you can delete PSA data or else you can delete after some time.
    Or check the below link which explain how to get delta from flat file using an ABAP routine...
    http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/a0b3f0e2-832d-2c10-1ca9-d909ca40b54e?quicklink=index&overridelayout=true

  • Dynamic LOV on form in update mode

    I have a link to a portal form that specifies the primary key as below:
    Portal30.wwv_user_utilities.get_url(
    'application.form_link',
    'primary_id',to_char(id),
    '_primary_id_cond','=');
    This works well. I can access the form in update mode for the specified row. However, on the form I have 2 combo boxes: one is for make of vehicle and the other for model. The make combo box uses an lov derived from a simple table query. The model combo box is a dynamic lov using a query based upon the value of the model. When entering the form in update mode, it fails to set the make bind variable to anything, so the model is left blank with no options. How can I set the value of the make bind variable on the link so I can get the dynamic lov for the model to be populated correctly?
    (I have already tried to add the model to the url link, to no avail).
    null

    Hi noor,
    When I click the link button I am opening the userdefined form and filling the corresponding document number details manually.
    Do you mean, you're filling the form, field by field???
    If so you're doing it wrong. That way the form has no connection to the correct Database record and cannot update it.
    The correct way is as follows:
    Put a DocEntry field in your form and bind it to the DocEntry database field.
    Set this field to NOT Visible by default.
    When a user clicks the LinkButton, you change the form mode to FindMode, make the DocEntry field visible use the oForm.Items.Item("DocEntry").Specific.Value = "" method to set the correct value to the field (use the DocEntry number NOT the DocNum) and use the oForm.Items.Item("1").Click() to open the correct record.
    Then the user can change the value it needs without errors.
    Best Regards,
    Vítor Vieira

  • R/3 Update Modes

    Hi All,
    We know that there are 3 update modes Direct Delta, Queued Delta and V3 update.
    Can somebody pls tell me what are the differences between these 3 and in which scenarios, we would prefer to use each of them?
    Also, do we use these methods only in Logistics? or in other modules also?
    Thanks in Advance,
    Regards,
    BIJESH

    Hi,
    Direct Delta:- In case of Direct delta LUWu2019s are directly posted to Delta Queue (RSA7) and we extract the LUWu2019s from Delta Queue to SAP BW by running Delta Loads. If we use Direct Delta it degrades the OLTP system performance because when LUWu2019s are directly posted to Delta Queue (RSA7) the application is kept waiting until all the enhancement code is executed.
    Queued Delta: - In case of Queued Delta LUWu2019s are posted to Extractor queue (LBWQ), by scheduling the V3 job we move the documents from Extractor queue (LBWQ) to Delta Queue (RSA7) and we extract the LUWu2019s from Delta Queue to SAP BW by running Delta Loads. Queued Delta is recommended by SAP it maintain the Extractor Log which us to handle the LUWu2019s, which are missed.
    Serialized V3 Update: - In case of Serialized V3 update LUWu2019s are posted to Update Queue (SM13), by scheduling the V3 job which move the documents from Extractor queue (LBWQ) to Delta Queue (RSA7) in a serialized fashion and we extract the LUWu2019s from Delta Queue to SAP BW by running Delta Loads. Since the LUWu2019s are moved in a Serial fashion from Update queue to Delta queue if we have any error document it doesnu2019t lift the subsequent documents and as it sorts the documents based on the creation time, there every possibility for frequent failures in V3 job and missing out the delta records. It also degrades the OLTP system performance as it forms multiple segments with respective to the change in the language.
    Un serialized V3 Update: - In case of Un serialized V3 update LUWu2019s are posted to Update Queue ( SM13 ), by scheduling the V3 job which move the documents from Extractor queue ( LBWQ ) to Delta Queue ( RSA7 ) and we extract the LUWu2019s from Delta Queue to SAP BW by running Delta Loads. Since the LUWu2019s are not moved in a Serial fashion from Update queue to Delta queue if we have any error document it considers the subsequent documents and no sorting of documents based on the creation time. It improves the OLTP system performance as it forms a segment for one language.
    Use LO job control /LBWE to schedule V3 jobs.
    LO-JOB CONTROL
    job controls
    LO-JOB CONTROL
    Delta Job Control
    LO Cookpit: when to set Job Control?
    Regarding Job Control in LBWE for Dueued Delta
    Job control
    job control
    Job Control
    Job control
    job control
    LBWQ and RSA7
    question on LBWQ and RSA7
    RSA7 Delta queues
    RSA7 Delta queues
    full update
    Regards
    TG

  • Diff between update modes

    hi guru's
    i have one doubt regarding lo extraction.
    we have 3 types of update modes in lo extraction. those are
    queued delta
    direct delta
    unserialized v3 update
    when will u go for each delta mode
    what are the advantages and disadvantages of each delta mode
    plz reply me asap.
    thank u
    from
    v.vijay

    Hi,
    Update Methods > Direct Delta, Queued, Non-serialized V3 Update and Serialized V3 (obsolete)
    Direct Delta
    Queued Delta
    Un-serialized V3 Update
    Serialized  V3 Update (obsolete)
    Direct Delta (update mode A): With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue. In doing so, each document posting with delta extraction is posted for exactly one LUW in the respective BW delta queues.
    • Each document posting is directly transferred into the BW delta queue
    • Each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
    Transaction postings lead to:
    1. Records in transaction tables and in update tables
    2. A periodically scheduled job transfers these postings into the BW delta queue
    3. This BW Delta queue is read when a delta load is executed.
    Pros:
    • Extraction is independent of V2 update
    • Less monitoring overhead of update data or extraction queue
    Cons:
    • Not suitable for environments with high number of document changes
    • Setup and delta initialization have to be executed successfully before document postings are resumed
    • V1 is more heavily burdened
    With this update mode, extraction data is transferred directly to the BW delta queues every time a document is posted. In this way, each document posted with delta extraction is converted to exactly one LUW in the related BW delta queues. If you are using this method, there is no need to schedule a job at regular intervals to transfer the data to the BW delta queues. On the other hand, the number of LUWs per DataSource increases significantly in the BW delta queues because the deltas of many documents are not summarized into one LUW in the BW delta queues as was previously the case for the V3 update.
    If you are using this update mode, note that you cannot post any documents during delta initialization in an application from the start of the recompilation run in the OLTP until all delta init requests have been successfully updated successfully in BW. Otherwise, data from documents posted in the meantime is irretrievably lost. The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method.
    This update method is recommended for the following general criteria:
    a) A maximum of 10,000 document changes (creating, changing or deleting documents) are accrued between two delta extractions for the application in question. A (considerably) larger number of LUWs in the BW delta queue can result in terminations during extraction.
    b) With a future delta initialization, you can ensure that no documents are posted from the start of the recompilation run in R/3 until all delta-init requests have been successfully posted. This applies particularly if, for example, you want to include more organizational units such as another plant or sales organization in the extraction. Stopping the posting of documents always applies to the entire client.
    Queued Delta: With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred as usual with the V3 update by means of an updating collective run into the BW delta queue. In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each DataSource into the BW delta queue, depending on the application.
    • Extraction data is collected for the affected application in an extraction queue
    • Collective run as usual for transferring data into the BW delta queue
    Transaction postings lead to:
    1. Records in transaction tables and in extraction queue
    2. A periodically scheduled job transfers these postings into the BW delta queue
    3. This BW Delta queue is read when a delta load is executed.
    Pros:
    • Extraction is independent of V2 update
    • Suitable for environments with high number of document changes
    • Writing to extraction queue is within V1-update: this ensures correct serialization
    • Downtime is reduced to running the setup
    Cons:
    • V1 is more heavily burdened compared to V3
    • Administrative overhead of extraction queue
    With this update mode, the extraction data for the affected application is compiled in an extraction queue (instead of in the update data) and can be transferred to the BW delta queues by an update collective run, as previously executed during the V3 update.
    Up to 10,000 delta extractions of documents to an LUW in the BW delta queues are cumulated in this way per DataSource, depending on the application.
    If you use this method, it is also necessary to schedule a job to regularly transfer the data to the BW delta queues ("update collective run"). However, you should note that reports delivered using the logistics extract structures Customizing cockpit are used during this scheduling. This scheduling is carried out with the same report which is used when you use the V3 updating (RMBWV311, RMBWV312 or RMBWV313).There is no point in scheduling with the RSM13005 report for this update method since this report only processes V3 update entries. The simplest way to perform scheduling is via the "Job control" function in the logistics extract structures Customizing Cockpit. We recommend that you schedule the job hourly during normal operation - that is, after successful delta initialization.
    In the case of a delta initialization, the document postings of the affected application can be included again after successful execution of the recompilation run in the OLTP (e.g OLI7BW, OLI8BW or OLI9BW), provided that you make sure that the update collective run is not started before all delta Init requests have been successfully updated in the BW.
    In the posting-free phase during the recompilation run in OLTP, you should execute the update collective run once (as before) to make sure that there are no old delta extraction data remaining in the extraction queues when you resume posting of documents.
    Using transaction SMQ1 and the queue names MCEX11, MCEX12 or MCEX13 you can get an overview of the data in the extraction queues.
    If you want to use the functions of the logistics extract structures Customizing cockpit to make changes to the extract structures of an application (for which you selected this update method), you should make absolutely sure that there is no data in the extraction queue before executing these changes in the affected systems. This applies in particular to the transfer of changes to a production system. You can perform a check when the V3 update is already in use in the respective target system using the RMCSBWCC check report.
    In the following cases, the extraction queues should never contain any data:
    - Importing an R/3 Support Package
    - Performing an R/3 upgrade
    For an overview of the data of all extraction queues of the logistics extract structures Customizing Cockpit, use transaction LBWQ. You may also obtain this overview via the "Log queue overview" function in the logistics extract structures Customizing cockpit. Only the extraction queues that currently contain extraction data are displayed in this case.
    The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method.
    This update method is recommended for the following general criteria:
    a) More than 10,000 document changes (creating, changing or deleting a document) are performed each day for the application in question.
    b) In future delta initializations, you must reduce the posting-free phase to executing the recompilation run in R/3. The document postings should be included again when the delta Init requests are posted in BW. Of course, the conditions described above for the update collective run must be taken into account.
    Un-serialized V3 Update: With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.
    • Extraction data for written as before into the update tables with a V3 update module
    • V3 collective run transfers the data to BW Delta queue
    • In contrast to serialized V3, the data in the updating collective run is without regard to sequence from the update tables
    Transaction postings lead to:
    1. Records in transaction tables and in update tables
    2. A periodically scheduled job transfers these postings into the BW delta queue
    3. This BW Delta queue is read when a delta load is executed.
    Issues:
    • Only suitable for data target design for which correct sequence of changes is not important e.g. Material Movements
    • V2 update has to be successful
    Note: Before PI Release 2002.1 the only update method available was V3 Update. As of PI 2002.1 three new update methods are available because the V3 update could lead to inconsistencies under certain circumstances. As of PI 2003.1 the old V3 update will not be supported anymore.
    With this update mode, the extraction data of the application in question continues to be written to the update tables using a V3 update module and is retained there until the data is read and processed by a collective update run.
    However, unlike the current default values (serialized V3 update); the data is read in the update collective run (without taking the sequence from the update tables into account) and then transferred to the BW delta queues.
    The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method since serialized data transfer is never the aim of this update method. However, you should note the following limitation of this update method:
    The extraction data of a document posting, where update terminations occurred in the V2 update, can only be processed by the V3 update when the V2 update has been successfully posted.
    This update method is recommended for the following general criteria:
    a) Due to the design of the data targets in BW and for the particular application in question, it is irrelevant whether or not the extraction data is transferred to BW in exactly the same sequence in which the data was generated in R/3.
    Serialized V3 (obsolete)
    • Transaction data is collected in the R/3 update tables
    • Data in the update tables is transferred through a periodic update process to BW Delta queue
    • Delta loads from BW retrieve the data from this BW Delta queue
    Transaction postings lead to:
    1. Records in transaction tables and in update tables
    2. A periodically scheduled job transfers these postings into the BW delta queue
    3. This BW Delta queue is read when a delta load is executed.
    Issues:
    • Even though it says serialized, correct sequence of extraction data cannot be guaranteed
    • V2 Update errors can lead to V3 updates never to be processed
    Thanks,
    JituK

  • Lock records when in Update Mode / problem with 2 users on 1 document

    Hi,
    when user A updates e.g. a purchase order and user B goes into this purchase order and updates e.g. the remark before user A, then user A cannot save his changes. Imagine user A has put in several new lines and has made several price adjustments, his work will be gone.
    In most cases this should not happen very often, but it could. Since B1 recognizes when another user has updated the document before, it should be possible to solve this situation more convenient (either by lock, saving to a new document, comparing to the old version, etc).
    Thank you
    Sebastian

    Hi Sebastian,
    Your request is understandable. It may not have big problem to change current process by coding. However to lock records whenever in update mode, that could create too many locks. It is basically not good for performance. The trade off may be allowing save as function. However, this may not be a desirable solution for most end users.
    Thanks,
    Gordon

  • Master Data loading got failed: error "Update mode R is not supported by th

    Hello Experts,
    I use to load master data for 0Customer_Attr though daily process chain, it was running successfully.
    For last 2 days master data loading for 0Customer_Attr got failed and it gives following error message:
    "Update mode R is not supported by the extraction API"
    Can anyone tell me what is that error for? how to resolve this issue?
    Regards,
    Nirav

    Hi
    Update mode R error will come in the below case
    You are running a delta (for master data) which afils due to some error. to resolve that error, you make the load red and try to repeat the load.
    This time the load will fail with update mode R.
    As repeat delta is not supported.
    So, now, the only thing you can do is to reinit the delta(as told in above posts) and then you can proceed. The earlier problem has nothing to do with update mode R.
    example your fiorst delta failed with replication issue.
    only replicating and repeaing will not solve the update mode R.
    you will have to do both replication of the data source and re-int for the update mode R.
    One more thing I would like to add is.
    If the the delat which failed with error the first time(not update mode R), then
    you have to do init with data transfer
    if it failed without picking any records,
    then do init without data transfer.
    Hope this helps
    Regards
    Shilpa
    Edited by: Shilpa Vinayak on Oct 14, 2008 12:48 PM

  • ERROR: Update mode C is not supported by the extraction API - R3 11

    Hi gurus,
    I just tryed to implement the solution I found at this link:
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d3219af2-0c01-0010-71ac-dbb4356cf4bf
    The data source is based on an Infoset on the KONV R/3 Table.
    I setted the AIM delta process and I did all the activities as written in the document.
    The process works if I load data to bw in "full", with "Init without data transfer" and "delta" mode. Of course if I change a Purchase document, it will be posted in the delta queue and then loaded to bw with the next delta load.
    The "initialize delta process" (with data) doesen't work and returns the following error:
    Update mode C is not supported by the extraction API
    the error code is R3 11.
    have you any idea about it???
    Thanks!!!
    Regards!
    Matteo

    Hi,
    for me it sounds quite simple. It is that the update mode 'C' get flagged as 'not allowed' for this extractor. Did you check with rsa3? I guess you will get the same error message. May be you can start debugging in rsa3 to find the place where the update mode gets checked.
    Anyway, it shouldn't be a issue as you have a workaround. May be you should raise a error message at sap because of this.
    regards
    Siggi

  • Logical  system name to be updated while client copy--URGENT HELP REQUIRED

    Hello All,
       I have a  query regarding the "Logical System name" updation during Client copy.
      When we make a client copy(SRM Masters) for the Production system(SRM),the Old Logical system name for backend(which is attached to the SRM masters) gets copied to the new Client (Copy) which needs to be updated.
      There is  a  std transaction BDLS through whcih w e can change the current Logical system name to  a  new one but this  seems to work fine for System copy but not for Client copy.
      So when i make  a client copy of  SRM masters  for Production system,is there  any other std  way wherein i can change the "Logical system name " for the  backend or  do i have  to write a  CUSTOM program wherein entries  for  the Backend Logical system name in tables like CRMMLSGUID will  be updated  with  the new  Logical system name?
       Any help on this is  appreciated.
    Thanks & Regards,
    Disha.

    Disha,
    Yes, I did it twice and it worked fine.
    The R/3 GUID is sent by the OLTP system (R/3) in R/3 message header.
    SRM checks this GUID in CRMMLSGUID table.
    If is not the same one, then replication process fails.
    The only solution I found was to delete this entry. It is automatically recreated with the new GUID with the next replication, with FM CRMT_OLTP_LOGSYS1, called in BAPI_CRM_SAVE.
    Look at OSS note 588701 & 765018 for deletion of CRMMLSGUID.
    The issue is exactly ours: around system/client copy.
    In an CRM environment, this is more critical, because we make a huge use of the middleware. But in our case, and especially after system/client copies, we can go, even if SAP does not guaranty anything, because we don't care about "old" replicated data (I don't care about old BDOCs, that should even be deleted after processing).
    We have to take some risks sometimes...
    Rgds
    Christophe

  • In the latest version of Pages (5.0) I cannot find the refresh button to update a chart copied from Numbers (also latest version 3.0). Can anyone help?

    In the latest version of Pages (5.0) I cannot find the refresh button to update a chart copied from Numbers (also latest version 3.0). I saved my Numbers document before copying to Pages. Can anyone help?

    I think you identified my mistake. I confused tables-charts-graphs. I was wanting a "table" of cells (numbers) to be added to the Pages document. Is there no way to do that and keep the tables linked between Numbers09 and Pages09?
    An example would be a Numbers spreadsheet calculating a number (say, a product price) and that number (data) be linked to a product information text in Pages.
    I just recently saw the Merge function in Pages, but have not yet learned how that works. I don't use Pages much at all but it would come in handy for creating to information sheets about products --- with the product pricing being updated from a Numbers spreadsheet.
    If you have any hints on how that can be done or where I can find info on that I would appreciate it.
    Thanks for catching my misunderstanding.
    Bill

  • How to use a single page for create and update mode.

    Hi,
    I need to develop a single page to be used for both create and update modes.
    I am going to use a variable MODE
    and i will set this in the emp summary page.
    Based on the button clicked by the user i have to render the JSF page.
    For tis if the user selects a perticular and cliks on update thn i will pass the empno to the next.
    so there in the next i will appy a ViewCreiteria on my View Obj to fetch only that row so that only that emp will be displayed ion update mode.
    This is working fione for me.
    So now the issue is
    when the user clicks on CreatEmp button.
    i need to enable my VO for insert operations.
    for this i wrote the code like this in the beforePhase event
    FacesContext ctx = FacesContext.getCurrentInstance();
    ValueBinding valBinding = ctx.getApplication().createValueBinding("#{data}");
    BindingContext bContext = (BindingContext) valBinding.getValue(ctx);
    DCDataControl dcControl = bContext.findDataControl("DataControl");
    Application app = ctx.getApplication();
    ApplicationModule am = (ApplicationModule) dcControl.getDataProvider();
    System.out.println("After Appmodule initiation");
    // get the VO reference and initiate the query
    System.out.println("Before Page VO initiation");
    PrismDmPageSectionViewImpl vo = (ViewImpl)am.findViewObject("View");
    //ViewRowImpl row = (ViewRowImpl) vo.createRow();
    /* TO CREATE AN EMPTY ROW*/
    Row row=vo.createRow();
    System.out.println("New Row is created");
    //vo.createKey(row);
    vo.insertRow(row);
    vo.setCurrentRow(row);
    By doing this a new empty page is rendered.
    But when i fill up the values and click on ok.. i am getting the error like this..
    JBO-27023: Failed to validate all rows in a transaction.
    JBO-27027: Missing mandatory attributes for a row with key null of type View3
    JBO-27014: Attribute Id in View3 is required
    JBO-27014: Attribute PageeId in View3 is required
    Please point me out where i am missing.
    Thanks

    Hi,
    In my opinion you are over complicating things.
    This is what I do for using the sme page as both create and update without all this code.
    1) Create a browse page containing a an adf table with a select one component bound to your view object.
    2) Create an additional edit page containing only an edit form containing fields of your view object that your users must enter in order to add or edit rows.
    3) Link the pages in the JSF diagram with an "edit" navigation case from browse to edit page and a "return" navigation case from edit to browse (make sure that redirect option is NOT set on both cases)
    4) Remove the submit button from the edit page and add two application module bindings for the commit and rollback operations as command buttons in the form footer facet. Make sure that both buttons has an action of return and that their disabled property is set to false. You will probably change their labels to ok and cancel respectively.
    5) Drop a create action for your view object from the data control palette inside your page as a command button and set the action property to edit also.
    3) Set the action property of the view button to edit
    This should basically work without any code from your part. -- at least it does so for me -- if you like to make it a bit more funcy you may add am action listener inside your buttons and set a requeScope variable for example #{requestScope.editing} to true or false depending on the button clicked. Then add a title to your page with a value like #{requestScope.editing == true ? 'Editing record' : 'Adding a new record'}..
    Hope that helps.
    Thanassis

Maybe you are looking for

  • CX_HRPA_INVALID_PARAMETER DUMP

    hi Experts We have developed a function module which calculates certain amount based on certain criteria and update the amount in a wage type in Infotype 15. The function module calculates the amount , but when im trying to update infotype 15 using H

  • New search bar at bottom of page

    I have recently noticed a new search bar type thing at the bottom of the page when i use firefox. there is no name or brand to it, it doesnt show up in add on etc and i cant get rid of it! It has a X the Find: and a space to type in a search followed

  • Images too large to fit my screen, windows overlap etc.

    One day I opened firefox to get my emails from the web and my icons suddenly became the size of silver dollars and I was able to view approximately a third of the image on screen without scrolling to view. If I open the print control window I couldn'

  • What are the advantages of Using SAP ?

    what are the advantages of SAP when compared to other technologies? what are the basic advantages of SAP

  • Where I can define the order by for a dynamic SelectOneChoice list

    Hi I am using JDeveloper 10.1.3.1-Toplink/POJO for the DataModel and ADF JSF for disigned the web pages. My problem is that I can not find the way to order the element of a dynamic SelectOneChoice. Can anyone help me please? Thanasi