Demo for updating a transaction
hi all,
can anyone plz send me the demo for how to updata a transaction ,
not standard transaction like mm01,va01,me21 some what other transaction.why iam asking for some what other transaction when ever i was attending for interview they expecting some different transaction
plz help me ,so that i will be thankful to you.some differnt transaction with steps plzzzzzzzzzzz.
thank u all.
Hi,
create a new program and copy the below code.
Note:- create a flat file (with comma seperated) with the below structure.
Flat file Example:-
Material number,oldmaterial number (don't put this header in your flat file)
13571228,oldmaterial
13571229,oldmaterial1
save this file into your local path, make sure that the path should be given in the function module "GUI_UPLOAD" example:- "D:\MM02.TXT".
test this it will work.
copy from here.
DATA : BEGIN OF it_data OCCURS 0,
data(255),
END OF it_data .
DATA : BEGIN OF it_mat OCCURS 0,
matnr LIKE rmmg1-matnr,
bismt LIKE mara-bismt,
END OF it_mat.
DATA : BEGIN OF it_error OCCURS 0,
matnr LIKE mara-matnr,
mess(255),
END OF it_error.
DATA : it_bdcdata LIKE bdcdata OCCURS 0 WITH HEADER LINE,
it_bdcmsgcoll LIKE bdcmsgcoll OCCURS 0 WITH HEADER LINE,
v_text(200).
PERFORM upload.
LOOP AT it_data.
PERFORM pop_mat.
ENDLOOP.
LOOP AT it_mat.
PERFORM pop_bdcdata.
REFRESH it_bdcmsgcoll.
CLEAR it_bdcmsgcoll.
CALL TRANSACTION 'MM02' USING it_bdcdata
UPDATE 'S'
MODE 'A'
MESSAGES INTO it_bdcmsgcoll.
IF sy-subrc NE 0.
LOOP AT it_bdcmsgcoll WHERE msgtyp = 'E' OR
msgtyp = 'A' OR
msgtyp = 'S'.
CALL FUNCTION 'FORMAT_MESSAGE'
EXPORTING
id = it_bdcmsgcoll-msgid
lang = sy-langu
no = it_bdcmsgcoll-msgnr
v1 = it_bdcmsgcoll-msgv1
v2 = it_bdcmsgcoll-msgv2
v3 = it_bdcmsgcoll-msgv3
v4 = it_bdcmsgcoll-msgv4
IMPORTING
msg = v_text
EXCEPTIONS
NOT_FOUND = 1
OTHERS = 2
IF sy-subrc NE 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
CONCATENATE it_error-mess v_text INTO it_error-mess.
ENDLOOP.
it_error-matnr = it_mat-matnr.
APPEND it_error.
CLEAR it_error.
ENDIF.
ENDLOOP.
LOOP AT it_error.
WRITE : it_error-matnr, it_error-mess.
ENDLOOP.
FORM upload .
CALL FUNCTION 'GUI_UPLOAD'
EXPORTING
filename = 'D:\sreeram\MM02.TXT'
filetype = 'ASC'
TABLES
data_tab = it_data .
IF sy-subrc NE 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDFORM. " UPLOAD
FORM pop_mat .
SPLIT it_data AT ',' INTO it_mat-matnr
it_mat-bismt.
APPEND it_mat.
CLEAR it_mat.
ENDFORM. " POP_BDCDATA
FORM pop_bdcdata .
REFRESH it_bdcdata.
CLEAR it_bdcdata.
PERFORM fill_screen USING 'SAPLMGMM' '0060' 'X'.
PERFORM fill_valus USING 'BDC_CURSOR'
'RMMG1-MATNR'.
PERFORM fill_valus USING 'RMMG1-MATNR'
it_mat-matnr.
PERFORM fill_valus USING 'BDC_OKCODE'
'=AUSW'.
PERFORM fill_screen USING 'SAPLMGMM' '0070' 'X'.
PERFORM fill_valus USING 'BDC_CURSOR'
'MSICHTAUSW-DYTXT(01)'.
PERFORM fill_valus USING 'MSICHTAUSW-KZSEL(01)'
'X'.
PERFORM fill_valus USING 'BDC_OKCODE'
'=ENTR'.
PERFORM fill_screen USING 'SAPLMGMM' '4004' 'X'.
PERFORM fill_valus USING 'BDC_CURSOR'
'MARA-BISMT'.
PERFORM fill_valus USING 'MARA-BISMT'
it_mat-bismt.
PERFORM fill_valus USING 'BDC_OKCODE'
'=BU'.
ENDFORM. " POP_BDCDATA
FORM fill_screen USING p_prog
p_dynpro
p_dynbegin.
it_bdcdata-program = p_prog.
it_bdcdata-dynpro = p_dynpro.
it_bdcdata-dynbegin = p_dynbegin.
APPEND it_bdcdata.
CLEAR it_bdcdata.
ENDFORM. " FILL_SCREEN
FORM fill_valus USING p_fnam
p_fval.
it_bdcdata-fnam = p_fnam.
it_bdcdata-fval = p_fval.
APPEND it_bdcdata.
CLEAR it_bdcdata.
ENDFORM. " FILL_VALUS
End of copy
Also see this :
Here iam giving just recorded sample code.here material number is ASNFINAL.
Old material number changed is :'OLD_BSIMT'.
perform bdc_dynpro using 'SAPLMGMM' '0060'.
perform bdc_field using 'BDC_CURSOR'
'RMMG1-MATNR'.
perform bdc_field using 'BDC_OKCODE'
'=ENTR'.
perform bdc_field using 'RMMG1-MATNR'
'ASNFINAL'.
perform bdc_dynpro using 'SAPLMGMM' '0070'.
perform bdc_field using 'BDC_CURSOR'
'MSICHTAUSW-DYTXT(01)'.
perform bdc_field using 'BDC_OKCODE'
'=ENTR'.
perform bdc_field using 'MSICHTAUSW-KZSEL(01)'
'X'.
perform bdc_dynpro using 'SAPLMGMM' '4004'.
perform bdc_field using 'BDC_OKCODE'
'=BU'.
perform bdc_field using 'MAKT-MAKTX'
'ASN FINAL TEST MATERIAL'.
perform bdc_field using 'BDC_CURSOR'
'MARA-BISMT'.
perform bdc_field using 'MARA-MEINS'
'EA'.
perform bdc_field using 'MARA-MATKL'
'AS02'.
perform bdc_field using 'MARA-BISMT'
'OLD_BSIMT'.
perform bdc_field using 'MARA-SPART'
'10'.
perform bdc_field using 'MARA-PRDHA'
'RC2120'.
perform bdc_field using 'MARA-GEWEI'
'KG'.
Reward Points if found helpfull..
Cheers,
Chandra Sekhar.
Similar Messages
-
Re: Transactions and Locking Rows for Update
Dale,
Sounds like you either need an "optimistic locking" scheme, usually
implemented with timestamps at the database level, or a concurrency manager.
A concurrency manager registers objects that may be of interest to multiple
users in a central location. It takes care of notifying interested parties
(i.e., clients,) of changes made to those objects, using a "notifier" pattern.
The optimistic locking scheme is relatively easy to implement at the
database level, but introduces several problems. One problem is that the
first person to save their changes "wins" - every one else has to discard
their changes. Also, you now have business policy effectively embedded in
the database.
The concurrency manager is much more flexible, and keeps the policy where
it probably belongs. However, it is more complex, and there are some
implications to performance when you get to the multiple-thousand-user
range because of its event-based nature.
Another pattern of lock management that has been implemented is a
"key-based" lock manager that does not use events, and may be more
effective at managing this type of concurrency for large numbers of users.
There are too many details to go into here, but I may be able to give you
more ideas in a separate note, if you want.
Don
At 04:48 PM 6/5/97 PDT, Dale "V." Georg wrote:
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save'button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
>
>
>
>
====================================
Don Nelson
Senior Consultant
Forte Software, Inc.
Denver, CO
Corporate voice mail: 510-986-3810
aka: [email protected]
====================================
"I think nighttime is dark so you can imagine your fears with less
distraction." - CalvinWe have taken an optimistic data locking approach. Retrieved values are
stored as initial values; changes are stored seperately. During update, key
value(s) or the entire retieved set is used in a where criteria to validate
that the data set is still in the initial state. This allows good decoupling
of the data access layer. However, optimistic locking allows multiple users
to access the same data set at the same time, but then only one can save
changes, the rest would get an error message that the data had changed. We
haven't had any need to use a pessimistic lock.
Pessimistic locking usually involves some form of open session or DBMS level
lock, which we haven't implemented for performance reasons. If we do find the
need for a pessimistic lock, we will probably use cached data sets that are
checked first, and returned as read-only if already in the cache.
-DFR
Dale V. Georg <[email protected]> on 06/05/97 03:25:02 PM
To: Forte User Group <[email protected]> @ INTERNET
cc: Richards* Debbie <[email protected]> @ INTERNET, Gardner*
Steve <[email protected]> @ INTERNET
Subject: Transactions and Locking Rows for Update
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for
any
ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
------ Message Header Follows ------
Received: from pebble.Sagesoln.com by notes.bsginc.com
(PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
id AA-1997Jun05.162418.1771.334203; Thu, 05 Jun 1997 16:24:19 -0500
Received: (from sync@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11825 for forte-users-outgoing; Thu, 5 Jun 1997 13:47:58 -0700
Received: (from uucp@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11819 for <[email protected]>; Thu, 5 Jun 1997 13:47:56 -0700
Received: from unknown(207.159.84.4) by pebble.sagesoln.com via smap (V1.3)
id sma011817; Thu Jun 5 13:47:43 1997
Received: from tes0001.macktrucks.com by relay.macktrucks.com
via smtpd (for pebble.sagesoln.com [206.80.24.108]) with SMTP; 5 Jun
1997 19:35:31 UT
Received: from dale by tes0001.macktrucks.com (SMI-8.6/SMI-SVR4)
id QAA04637; Thu, 5 Jun 1997 16:45:51 -0400
Message-ID: <[email protected]>
Priority: Normal
To: Forte User Group <[email protected]>
Cc: "Richards," Debbie <[email protected]>,
"Gardner," Steve <[email protected]>
MIME-Version: 1.0
From: Dale "V." Georg <[email protected]>
Subject: Transactions and Locking Rows for Update
Date: Thu, 05 Jun 97 16:48:37 PDT
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk
Reply-To: Dale "V." Georg <[email protected]> -
Transactions and Locking Rows for Update
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------ -
User exit/BADI for updating custom table in MB1B transaction-
Dear All,
When performing a material to material conversion in MB1B transaction for batch managed materials,system is creating a new batch by copying the characteristics of issuing material/batch.The details of the new batch created are updated in standard batch tables(MCH1,MCHA,MCHA).
The requirement is when the new batch is created,the batch details and characteristics has to be stamped in a custom table.
Kindly suggest a user exit/BAIi available for updating the same in the custom table.
Regards,
DeepakDeepak, Exits for MB1B are
MBCF0002 Customer function exit: Segment text in material doc. item
MBCF0005 Material document item for goods receipt/issue slip
MBCF0006 Customer function for WBS element
MBCF0007 Customer function exit: Updating a reservation
MBCF0009 Filling the storage location field
MBCF0010 Customer exit: Create reservation BAPI_RESERVATION_CREATE1
MBCF0011 Read from RESB and RKPF for print list in MB26
MB_CF001 Customer Function Exit in the Case of Updating a Mat. Doc. -
XD02 transaction to change the customer data for updating KNA1 table?
Hi all,
How can we use XD02 transaction to change the customer data for updating KNA1 table?
Give the steps.
Thanks in advance
rkHi KR,
Why don't u use BDC to run XD02.
With Regards,
Zafar Ali -
Create of (demo for)OVAI (transaction for create entries for each vendor)
hi all,
can anyone plz tell me how 2 create (demo for)OVAI (transaction for create entries for each vendor)
thans & regards,
srinivas reddy.hiii
yes you can call transaction like that..take tcode in that parameter then you can use it in your program with statement like
call transaction (variable)..in background process.
regards
twinkal -
Create transaction for update a custom table
Hi,
I have a custom table Z****. What are all the steps to create a transaction for updating my custom table? I don't want to use SM30 anymore.
Thank you.Create a Table maintainence through the maintainence generator.
Open table in SE11, goto utilities => table maintainence generator.
Once the generator is created,
In the same screen of generator - Goto Environment => Transaction Code
Select Transaction Code with Parameter.
In the default values - Enter the Transaction as SM30 . Select skip first screen.
In default values at the bottom
Add
screen field = VIEWNAME and value = Ztable name.
screen field =UPDATE and value = 'X'.
Edited by: Pranu Pranu on May 19, 2010 2:36 PM -
Problem with "SELECT...FOR UPDATE OF..." and "POST command" combination
Problem with "SELECT...FOR UPDATE OF..." and "POST command" combination
Problem in committing transactions in Multiple Forms (Oracle Forms) with POST built-in command:
Consider that the following statements are written in WHEN-WINDOW-CLOSED trigger of a called form.
Statements in called form (Form name: FORM_CHILD):
go_block('display_block') ;
do_key('execute_query') ;
-- Data from table_b will be populated in this block, based on the value of COLUMN_1 obtained
-- from TABLE_A.
-- Example: If the value of COLUMN_1 is 10, then all the matching records from TABLE_B, which
-- are inserted with value 10 in TABLE_B.COLUMN_1 will be fetched and shown here.
if user_choice = 'YES' then
commit ;
else
rollback ;
end if ;
Statements in calling forms:
There are two calling forms having following statements and it is going to call the above said called form.
CALLING FORM 1
Statements in KEY-COMMIT trigger:
post;
call_form(form_child, no_activate) ;
Statements in ON-INSERT trigger:
select column_1
from table_a
for update of column_1
where column_2 = 'X' ;
update table_a
set column_1 = column_1 + 1
where column_2 = 'X' ;
insert into table_b ...;
insert into table_b ...; Statements in KEY-COMMIT trigger:
post;
call_form(form_child, no_activate) ;
CALLING FORM 2:
Statements in ON-INSERT trigger:
select column_1
from table_a
for update of column_1
where column_2 = 'X' ;
update table_a
set column_1 = column_1 + 1
where column_2 = 'X' ;
insert into table_b ...;
insert into table_b ...;
insert into table_b ...;
Our understanding:
Assume that both the forms are running from two different machines/instances, issuing commit at the same time. In this case, forms will start executing the statements written in ON-INSERT trigger, the moment POST command is executed. Though the commit is issued at the same time, according to oracle, only one of the request will be taken for processing first. Assume that calling form 1 is getting processed first.
So, it fetches the value available in COLUMN_1 of TABLE_A and locks the row from further select, update, etc. as SELECT...FOR UPDATE command is used (note that NOWAIT is not given, hence the lock will be released only when COMMIT or ROLLBACK happens) and proceed executing further INSERT statements. Because of the lock provided by the SELECT...FOR UPDATE command, the statements in calling form 2 will wait for the resource.
After executing the INSERT statements, the FORM_CHILD is called. The rows inserted in to TABLE_A will be queried and shown. The database changes will be committed when user closes the window (as COMMIT is issued in its WHEN-WINDOW-CLOSED trigger). Then the SELECT...FOR UPDATE lock will be released and calling form 2's statements will be executed.
Actual happenings or Mis-behavior:
Calling form 2 starts executing INSERT statements instead of waiting for SELECT...FOR UPDATE lock. Also, the value selected from TABLE_A.COLUMN_1 is same in both the calling forms, which is wrong.
The rows inserted into TABLE_B are having similar COLUMN_1 values in calling form 2 and they are fetched and shown in the called form FORM_CHILD.
Note that in calling form 2 also POST only is issued, but the changes posted there are accessible in calling form 1 also, which is wrong.
Kindly suggest us as to how to fix above problem. It will be much use, if you can send us the information regarding the behavior of Oracle Forms POST built-in also.
Our mail ID: [email protected]
Thanks a lot in advance.You have several problems:
1. On-Insert will ONLY run if you have created a new record in a base-table block. If you haven't done that, then the POST command will not cause it to run.
2. Select for update without a "no wait" will lock records for the first form, but when the second form tries this, it will hit the ORA-00054 exception, and will NOT wait. The only way you could make it wait is to issue an UPDATE sql command, which is not such a good way to go.
All POST does is issues SQL insert or update commands for any changes the user has made to records in a form's base-table blocks, without following with a Commit command.
Also understand that Commit is the same as Commit_Form, and Rollback is the same as Clear_Form. You should read up on these in the Forms help topics. -
Eng_eco_pub.process_Eco for UPDATE of effectivity_date on revised items
Hi All,
We are on Oracle Applications Rel 11.5.8.
We are trying to update an existing ECO with an ‘UPDATE’ transaction_type using eng_Eco_pub API. Here is the code. We first execute this script with CREATE and ECO is created. However, when we run the same script to UPDATE with transaction_type = ‘UPDATE’, the bill_sequence_id in eng_revised_items is updated to g_miss_num (9.99E125). The API is returning ‘SUCCESS’ and updates the bill_sequence_id to 9.999E125. Not sure what we are missing here. Appreciate any inputs or sample code for UPDATING an already created ECO.
REVISED_ITEM_ID BILL_SEQUENCE_ID CHANGE_NOTICE
11668210 192981011 IK-API0316
REVISED_ITEM_ID BILL_SEQUENCE_ID CHANGE_NOTICE
11668210 9.99E125 IK-API0316
Thank You!
DECLARE
l_eco_name VARCHAR2(10) := 'IK-API0000' ;
l_org_code VARCHAR2(3) := 'GLO';
l_transaction_type VARCHAR2(10) := 'CREATE'; -- or UPDATE for updating the same ECO
l_rev_item_number1 VARCHAR2(20):= '16-2214-01';
l_eff_date DATE := NULL;
v_old_effective_date DATE;
l_new_revised_item_revision VARCHAR2(3) := '-A0';
l_eco_rec Eng_Eco_Pub.Eco_Rec_Type := Eng_Eco_Pub.g_miss_eco_rec;
l_eco_revision_tbl Eng_Eco_Pub.Eco_Revision_Tbl_Type := Eng_Eco_Pub.g_miss_eco_revision_tbl;
l_revised_item_tbl Eng_Eco_Pub.Revised_Item_Tbl_Type ;-- := Eng_Eco_Pub.g_miss_revised_item_tbl;
l_rev_component_tbl Bom_Bo_Pub.Rev_Component_Tbl_Type := Eng_Eco_Pub.g_miss_rev_component_tbl;
l_sub_component_tbl Bom_Bo_Pub.Sub_Component_Tbl_Type := Eng_Eco_Pub.g_miss_sub_component_tbl;
l_ref_designator_tbl Bom_Bo_Pub.Ref_Designator_Tbl_Type := Eng_Eco_Pub.g_miss_ref_designator_tbl;
l_rev_operation_tbl Bom_Rtg_Pub.Rev_Operation_Tbl_Type := Eng_Eco_Pub.g_miss_rev_operation_tbl;
l_rev_op_resource_tbl Bom_Rtg_Pub.Rev_Op_Resource_Tbl_Type := Eng_Eco_Pub.g_miss_rev_op_resource_tbl;
l_rev_sub_resource_tbl Bom_Rtg_Pub.Rev_Sub_Resource_Tbl_Type := Eng_Eco_Pub.g_miss_rev_sub_resource_tbl;
-- API output variables
x_eco_rec Eng_Eco_Pub.Eco_Rec_Type := Eng_Eco_Pub.g_miss_eco_rec;
x_eco_revision_tbl Eng_Eco_Pub.Eco_Revision_Tbl_Type := Eng_Eco_Pub.g_miss_eco_revision_tbl;
x_revised_item_tbl Eng_Eco_Pub.Revised_Item_Tbl_Type ;-- := Eng_Eco_Pub.g_miss_revised_item_tbl;
x_rev_component_tbl Bom_Bo_Pub.Rev_Component_Tbl_Type := Eng_Eco_Pub.g_miss_rev_component_tbl;
x_sub_component_tbl Bom_Bo_Pub.Sub_Component_Tbl_Type := Eng_Eco_Pub.g_miss_sub_component_tbl;
x_ref_designator_tbl Bom_Bo_Pub.Ref_Designator_Tbl_Type := Eng_Eco_Pub.g_miss_ref_designator_tbl;
x_rev_operation_tbl Bom_Rtg_Pub.Rev_Operation_Tbl_Type := Eng_Eco_Pub.g_miss_rev_operation_tbl;
x_rev_op_resource_tbl Bom_Rtg_Pub.Rev_Op_Resource_Tbl_Type := Eng_Eco_Pub.g_miss_rev_op_resource_tbl;
x_rev_sub_resource_tbl Bom_Rtg_Pub.Rev_Sub_Resource_Tbl_Type := Eng_Eco_Pub.g_miss_rev_sub_resource_tbl;
-- Other API variables for return status / error handling / debugging
l_error_table Error_Handler.Error_Tbl_Type;
l_return_status VARCHAR2(1) := NULL;
l_msg_count NUMBER := 0;
l_output_dir VARCHAR2(500) := '/apps/orarpt/SJDEV/utl';
l_debug_filename VARCHAR2(60) := 'test.dbg';
-- WHO columns
l_user_id NUMBER := -1;
l_resp_id NUMBER := -1;
l_application_id NUMBER := -1;
l_row_cnt NUMBER := 1;
l_user_name VARCHAR2(30) := 'CA_ADMIN';
l_resp_name VARCHAR2(30) := 'Engineering';
l_comp_eff_date date := null;
l_disable_date date := null;
BEGIN
-- Get the user_id
SELECT user_id,sysdate + 10,sysdate
INTO l_user_id,l_comp_eff_date,l_eff_date
FROM fnd_user
WHERE user_name = l_user_name;
-- Get the application_id and responsibility_id
SELECT application_id, responsibility_id
INTO l_application_id, l_resp_id
FROM fnd_responsibility_tl
WHERE responsibility_name = l_resp_name;
FND_GLOBAL.APPS_INITIALIZE(l_user_id, l_resp_id, l_application_id); -- Mfg / Mfg & Dist Mgr / INV
dbms_output.put_line('Initialized applications context: '|| l_user_id || ' '|| l_resp_id ||' '|| l_application_id );
dbms_output.put_line('before initialixe');
Error_Handler.Initialize;
l_return_status := NULL;
dbms_output.put_line('after initialixe');
-- FOR UPDATE API to update effectivity date on Revised item.
l_eco_rec.eco_name := l_eco_name;
l_eco_rec.organization_code := l_org_code;
l_eco_rec.change_type_code := 'DESIGN';
l_eco_rec.eco_department_name := NULL;
l_eco_rec.priority_code := NULL; --'Medium';
l_eco_rec.approval_list_name := NULL; --'SU_ONLY';
l_eco_rec.reason_code := NULL;
l_eco_rec.Approval_Status_TYPE := 5 ;-- 'Approved'; -- will default to Not submitted for Approval
l_eco_rec.Status_TYPE := 1; -- 1 to bring in SCHEDULE status
l_eco_rec.description := l_eff_date || ' - ECO - '||l_eco_rec.eco_name ;
l_eco_rec.transaction_type := l_transaction_type;
l_eco_rec.return_status := NULL;
IF l_transaction_type ='CREATE' THEN
l_revised_item_tbl(l_row_cnt).transaction_type := l_transaction_type; -- transaction type : CREATE / UPDATE
l_revised_item_tbl(l_row_cnt).eco_name := l_eco_name;
l_revised_item_tbl(l_row_cnt).organization_code := l_org_code;
l_revised_item_tbl(l_row_cnt).revised_item_name := l_rev_item_number1;
l_revised_item_tbl(l_row_cnt).new_revised_item_revision := '-A0'; -- pass only if the previous unimplemented updating ECO has a new revision
l_revised_item_tbl(l_row_cnt).Updated_Revised_Item_Revision := ''; -- l_new_revised_item_revision;
l_revised_item_tbl(l_row_cnt).start_effective_date := l_eff_date;
l_revised_item_tbl(l_row_cnt).new_effective_date := l_eff_date ; -- l_comp_eff_date;
l_revised_item_tbl(l_row_cnt).alternate_bom_code := null;
l_revised_item_tbl(l_row_cnt).status_type := 1; -- 'Open'
l_revised_item_tbl(l_row_cnt).change_description := l_rev_item_number1 || ' --B0 ECO - '||l_eco_rec.eco_name ;
l_revised_item_tbl(l_row_cnt).disposition_type :=1 ;
l_revised_item_tbl(l_row_cnt).update_wip := 1;--2
l_revised_item_tbl(l_row_cnt).mrp_active := 1;
--l_revised_item_tbl(l_row_cnt).new_item_revision:= '';
l_revised_item_tbl(l_row_cnt).new_routing_revision:= '';
l_revised_item_tbl(l_row_cnt).from_end_item_unit_number:= ''; -- this field is mandatory
l_revised_item_tbl(l_row_cnt).eco_for_production:=2;
l_revised_item_tbl(l_row_cnt).earliest_effective_date := l_eff_date;
l_revised_item_tbl(l_row_cnt).use_up_item_name := l_rev_item_number1; null;
--l_revised_item_tbl(l_row_cnt).use_up_plan_name :=null;
END IF;
IF l_transaction_type = 'UPDATE' THEN
FOR v_component in (SELECT * from eng_revised_items where change_notice = 'IK-API0000') LOOP
l_revised_item_tbl(l_row_cnt).eco_name := l_eco_name;
l_revised_item_tbl(l_row_cnt).organization_code := l_org_code;
l_revised_item_tbl(l_row_cnt).revised_item_name := l_rev_item_number1;
l_revised_item_tbl(l_row_cnt).new_revised_item_revision := '-A0';
l_revised_item_tbl(l_row_cnt).New_Revised_Item_Rev_Desc := '-F0 ik added';
l_revised_item_tbl(l_row_cnt).Updated_Revised_Item_Revision := '-F0';
l_revised_item_tbl(l_row_cnt).Start_Effective_Date := l_eff_date;
l_revised_item_tbl(l_row_cnt).New_Effective_Date := l_eff_date;
l_revised_item_tbl(l_row_cnt).Alternate_Bom_Code := v_component.alternate_bom_designator;
l_revised_item_tbl(l_row_cnt).Status_Type := v_component.status_type;
l_revised_item_tbl(l_row_cnt).Mrp_Active := v_component.Mrp_Active;
l_revised_item_tbl(l_row_cnt).Earliest_Effective_Date := sysdate;
l_revised_item_tbl(l_row_cnt).Requestor := '';
l_revised_item_tbl(l_row_cnt).Use_Up_Plan_Name := v_component.Use_Up_Plan_Name;
l_revised_item_tbl(l_row_cnt).Disposition_Type := v_component.Disposition_Type;
l_revised_item_tbl(l_row_cnt).Update_Wip := v_component.Update_Wip;
l_revised_item_tbl(l_row_cnt).Cancel_Comments := v_component.Cancel_Comments;
l_revised_item_tbl(l_row_cnt).Change_Description := 'TESTING ';
l_revised_item_tbl(l_row_cnt).Attribute_category := v_component.Attribute_category;
l_revised_item_tbl(l_row_cnt).Attribute1 := v_component.Attribute1;
l_revised_item_tbl(l_row_cnt).Attribute2 := v_component.Attribute2;
l_revised_item_tbl(l_row_cnt).Attribute3 := v_component.Attribute3;
l_revised_item_tbl(l_row_cnt).Attribute4 := v_component.Attribute4;
l_revised_item_tbl(l_row_cnt).Attribute5 := v_component.Attribute5;
l_revised_item_tbl(l_row_cnt).Attribute6 := v_component.Attribute6;
l_revised_item_tbl(l_row_cnt).Attribute7 := v_component.Attribute7;
l_revised_item_tbl(l_row_cnt).Attribute8 := v_component.Attribute8;
l_revised_item_tbl(l_row_cnt).Attribute9 := v_component.Attribute9;
l_revised_item_tbl(l_row_cnt).Attribute10 := v_component.Attribute10;
l_revised_item_tbl(l_row_cnt).Attribute11 := v_component.Attribute11;
l_revised_item_tbl(l_row_cnt).Attribute12 := v_component.Attribute12;
l_revised_item_tbl(l_row_cnt).Attribute13 := v_component.Attribute13;
l_revised_item_tbl(l_row_cnt).Attribute14 := v_component.Attribute14;
l_revised_item_tbl(l_row_cnt).Attribute15 := v_component.Attribute15;
l_revised_item_tbl(l_row_cnt).From_End_Item_Unit_Number := v_component.From_End_Item_Unit_Number;
l_revised_item_tbl(l_row_cnt).New_From_End_Item_Unit_Number := '';
l_revised_item_tbl(l_row_cnt).Original_System_Reference :=v_component.Original_System_Reference;
l_revised_item_tbl(l_row_cnt).Return_Status := '';
l_revised_item_tbl(l_row_cnt).Transaction_Type := l_transaction_type;
-- L1, the following is added for ECO enhancement
l_revised_item_tbl(l_row_cnt).From_Work_Order := '';
l_revised_item_tbl(l_row_cnt).To_Work_Order := '';
l_revised_item_tbl(l_row_cnt).From_Cumulative_Quantity := v_component.from_cum_qty;
l_revised_item_tbl(l_row_cnt).Lot_Number := v_component.Lot_Number;
l_revised_item_tbl(l_row_cnt).Completion_Subinventory := v_component.Completion_Subinventory;
l_revised_item_tbl(l_row_cnt).Completion_Location_Name :='';
l_revised_item_tbl(l_row_cnt).Priority := v_component.Priority;
l_revised_item_tbl(l_row_cnt).Ctp_Flag := v_component.Ctp_Flag;
l_revised_item_tbl(l_row_cnt).New_Routing_Revision := v_component.New_Routing_Revision;
l_revised_item_tbl(l_row_cnt).Updated_Routing_Revision := '';
l_revised_item_tbl(l_row_cnt).Routing_Comment := v_component.Routing_Comment;
-- L1, the above is added for ECO enhancement
l_revised_item_tbl(l_row_cnt).Eco_For_Production := v_component.Eco_For_Production;
END LOOP;
END IF;
Eng_Eco_PUB.Process_Eco( p_api_version_number => 1.0
, p_init_msg_list => FALSE
, x_return_status => l_return_status
, x_msg_count => l_msg_count
, p_bo_identifier => 'ECO'
, p_eco_rec => l_eco_rec
, p_eco_revision_tbl => l_eco_revision_tbl
, p_revised_item_tbl => l_revised_item_tbl
, p_rev_component_tbl => l_rev_component_tbl
, p_ref_designator_tbl => l_ref_designator_tbl
, p_sub_component_tbl => l_sub_component_tbl
, p_rev_operation_tbl => l_rev_operation_tbl
, p_rev_op_resource_tbl => l_rev_op_resource_tbl
, p_rev_sub_resource_tbl => l_rev_sub_resource_tbl
, x_eco_rec => x_eco_rec
, x_eco_revision_tbl => x_eco_revision_tbl
, x_revised_item_tbl => x_revised_item_tbl
, x_rev_component_tbl => x_rev_component_tbl
, x_ref_designator_tbl => x_ref_designator_tbl
, x_sub_component_tbl => x_sub_component_tbl
, x_rev_operation_tbl => x_rev_operation_tbl
, x_rev_op_resource_tbl => x_rev_op_resource_tbl
, x_rev_sub_resource_tbl => x_rev_sub_resource_tbl
, p_debug => 'N'
, p_output_dir => l_output_dir
, p_debug_filename => l_debug_filename
dbms_output.put_line('after API call');
DBMS_OUTPUT.PUT_LINE('=======================================================');
DBMS_OUTPUT.PUT_LINE('=======================================================');
DBMS_OUTPUT.PUT_LINE('Return Status: '||l_return_status);
dbms_output.put_line('x_eco_rec.eco_name:'|| x_eco_rec.eco_name );
dbms_output.put_line('x_eco_rec.org_code:'|| x_eco_rec.organization_code);
IF (l_return_status = 'E') THEN
dbms_output.put_line('x_msg_count:' || l_msg_count);
Error_Handler.GET_MESSAGE_LIST(x_message_list => l_error_table);
DBMS_OUTPUT.PUT_LINE('Error Message Count :'||l_error_table.COUNT);
FOR i IN 1..l_error_table.COUNT LOOP
--DBMS_OUTPUT.PUT_LINE(to_char(i)||':'||l_error_table(i).entity_index||':'||l_error_table(i).table_name);
DBMS_OUTPUT.PUT_LINE(to_char(i)||':'||l_error_table(i).entity_index||':');
DBMS_OUTPUT.PUT_LINE(to_char(i)||':'||substr(l_error_table(i).message_text,1,250));
END LOOP;
--ROLLBACK;
ELSE
DBMS_OUTPUT.PUT_LINE('==COMMITING==');
--COMMIT;
END IF;
DBMS_OUTPUT.PUT_LINE('=======================================================');
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('Exception Occured :');
DBMS_OUTPUT.PUT_LINE(SQLCODE ||':'||SQLERRM);
DBMS_OUTPUT.PUT_LINE('=======================================================');
RAISE;
END;Hi All,
We are on Oracle Applications Rel 11.5.8.
We are trying to update an existing ECO with an ‘UPDATE’ transaction_type using eng_Eco_pub API. Here is the code. We first execute this script with CREATE and ECO is created. However, when we run the same script to UPDATE with transaction_type = ‘UPDATE’, the bill_sequence_id in eng_revised_items is updated to g_miss_num (9.99E125). The API is returning ‘SUCCESS’ and updates the bill_sequence_id to 9.999E125. Not sure what we are missing here. Appreciate any inputs or sample code for UPDATING an already created ECO.
REVISED_ITEM_ID BILL_SEQUENCE_ID CHANGE_NOTICE
11668210 192981011 IK-API0316
REVISED_ITEM_ID BILL_SEQUENCE_ID CHANGE_NOTICE
11668210 9.99E125 IK-API0316
Thank You!
DECLARE
l_eco_name VARCHAR2(10) := 'IK-API0000' ;
l_org_code VARCHAR2(3) := 'GLO';
l_transaction_type VARCHAR2(10) := 'CREATE'; -- or UPDATE for updating the same ECO
l_rev_item_number1 VARCHAR2(20):= '16-2214-01';
l_eff_date DATE := NULL;
v_old_effective_date DATE;
l_new_revised_item_revision VARCHAR2(3) := '-A0';
l_eco_rec Eng_Eco_Pub.Eco_Rec_Type := Eng_Eco_Pub.g_miss_eco_rec;
l_eco_revision_tbl Eng_Eco_Pub.Eco_Revision_Tbl_Type := Eng_Eco_Pub.g_miss_eco_revision_tbl;
l_revised_item_tbl Eng_Eco_Pub.Revised_Item_Tbl_Type ;-- := Eng_Eco_Pub.g_miss_revised_item_tbl;
l_rev_component_tbl Bom_Bo_Pub.Rev_Component_Tbl_Type := Eng_Eco_Pub.g_miss_rev_component_tbl;
l_sub_component_tbl Bom_Bo_Pub.Sub_Component_Tbl_Type := Eng_Eco_Pub.g_miss_sub_component_tbl;
l_ref_designator_tbl Bom_Bo_Pub.Ref_Designator_Tbl_Type := Eng_Eco_Pub.g_miss_ref_designator_tbl;
l_rev_operation_tbl Bom_Rtg_Pub.Rev_Operation_Tbl_Type := Eng_Eco_Pub.g_miss_rev_operation_tbl;
l_rev_op_resource_tbl Bom_Rtg_Pub.Rev_Op_Resource_Tbl_Type := Eng_Eco_Pub.g_miss_rev_op_resource_tbl;
l_rev_sub_resource_tbl Bom_Rtg_Pub.Rev_Sub_Resource_Tbl_Type := Eng_Eco_Pub.g_miss_rev_sub_resource_tbl;
-- API output variables
x_eco_rec Eng_Eco_Pub.Eco_Rec_Type := Eng_Eco_Pub.g_miss_eco_rec;
x_eco_revision_tbl Eng_Eco_Pub.Eco_Revision_Tbl_Type := Eng_Eco_Pub.g_miss_eco_revision_tbl;
x_revised_item_tbl Eng_Eco_Pub.Revised_Item_Tbl_Type ;-- := Eng_Eco_Pub.g_miss_revised_item_tbl;
x_rev_component_tbl Bom_Bo_Pub.Rev_Component_Tbl_Type := Eng_Eco_Pub.g_miss_rev_component_tbl;
x_sub_component_tbl Bom_Bo_Pub.Sub_Component_Tbl_Type := Eng_Eco_Pub.g_miss_sub_component_tbl;
x_ref_designator_tbl Bom_Bo_Pub.Ref_Designator_Tbl_Type := Eng_Eco_Pub.g_miss_ref_designator_tbl;
x_rev_operation_tbl Bom_Rtg_Pub.Rev_Operation_Tbl_Type := Eng_Eco_Pub.g_miss_rev_operation_tbl;
x_rev_op_resource_tbl Bom_Rtg_Pub.Rev_Op_Resource_Tbl_Type := Eng_Eco_Pub.g_miss_rev_op_resource_tbl;
x_rev_sub_resource_tbl Bom_Rtg_Pub.Rev_Sub_Resource_Tbl_Type := Eng_Eco_Pub.g_miss_rev_sub_resource_tbl;
-- Other API variables for return status / error handling / debugging
l_error_table Error_Handler.Error_Tbl_Type;
l_return_status VARCHAR2(1) := NULL;
l_msg_count NUMBER := 0;
l_output_dir VARCHAR2(500) := '/apps/orarpt/SJDEV/utl';
l_debug_filename VARCHAR2(60) := 'test.dbg';
-- WHO columns
l_user_id NUMBER := -1;
l_resp_id NUMBER := -1;
l_application_id NUMBER := -1;
l_row_cnt NUMBER := 1;
l_user_name VARCHAR2(30) := 'CA_ADMIN';
l_resp_name VARCHAR2(30) := 'Engineering';
l_comp_eff_date date := null;
l_disable_date date := null;
BEGIN
-- Get the user_id
SELECT user_id,sysdate + 10,sysdate
INTO l_user_id,l_comp_eff_date,l_eff_date
FROM fnd_user
WHERE user_name = l_user_name;
-- Get the application_id and responsibility_id
SELECT application_id, responsibility_id
INTO l_application_id, l_resp_id
FROM fnd_responsibility_tl
WHERE responsibility_name = l_resp_name;
FND_GLOBAL.APPS_INITIALIZE(l_user_id, l_resp_id, l_application_id); -- Mfg / Mfg & Dist Mgr / INV
dbms_output.put_line('Initialized applications context: '|| l_user_id || ' '|| l_resp_id ||' '|| l_application_id );
dbms_output.put_line('before initialixe');
Error_Handler.Initialize;
l_return_status := NULL;
dbms_output.put_line('after initialixe');
-- FOR UPDATE API to update effectivity date on Revised item.
l_eco_rec.eco_name := l_eco_name;
l_eco_rec.organization_code := l_org_code;
l_eco_rec.change_type_code := 'DESIGN';
l_eco_rec.eco_department_name := NULL;
l_eco_rec.priority_code := NULL; --'Medium';
l_eco_rec.approval_list_name := NULL; --'SU_ONLY';
l_eco_rec.reason_code := NULL;
l_eco_rec.Approval_Status_TYPE := 5 ;-- 'Approved'; -- will default to Not submitted for Approval
l_eco_rec.Status_TYPE := 1; -- 1 to bring in SCHEDULE status
l_eco_rec.description := l_eff_date || ' - ECO - '||l_eco_rec.eco_name ;
l_eco_rec.transaction_type := l_transaction_type;
l_eco_rec.return_status := NULL;
IF l_transaction_type ='CREATE' THEN
l_revised_item_tbl(l_row_cnt).transaction_type := l_transaction_type; -- transaction type : CREATE / UPDATE
l_revised_item_tbl(l_row_cnt).eco_name := l_eco_name;
l_revised_item_tbl(l_row_cnt).organization_code := l_org_code;
l_revised_item_tbl(l_row_cnt).revised_item_name := l_rev_item_number1;
l_revised_item_tbl(l_row_cnt).new_revised_item_revision := '-A0'; -- pass only if the previous unimplemented updating ECO has a new revision
l_revised_item_tbl(l_row_cnt).Updated_Revised_Item_Revision := ''; -- l_new_revised_item_revision;
l_revised_item_tbl(l_row_cnt).start_effective_date := l_eff_date;
l_revised_item_tbl(l_row_cnt).new_effective_date := l_eff_date ; -- l_comp_eff_date;
l_revised_item_tbl(l_row_cnt).alternate_bom_code := null;
l_revised_item_tbl(l_row_cnt).status_type := 1; -- 'Open'
l_revised_item_tbl(l_row_cnt).change_description := l_rev_item_number1 || ' --B0 ECO - '||l_eco_rec.eco_name ;
l_revised_item_tbl(l_row_cnt).disposition_type :=1 ;
l_revised_item_tbl(l_row_cnt).update_wip := 1;--2
l_revised_item_tbl(l_row_cnt).mrp_active := 1;
--l_revised_item_tbl(l_row_cnt).new_item_revision:= '';
l_revised_item_tbl(l_row_cnt).new_routing_revision:= '';
l_revised_item_tbl(l_row_cnt).from_end_item_unit_number:= ''; -- this field is mandatory
l_revised_item_tbl(l_row_cnt).eco_for_production:=2;
l_revised_item_tbl(l_row_cnt).earliest_effective_date := l_eff_date;
l_revised_item_tbl(l_row_cnt).use_up_item_name := l_rev_item_number1; null;
--l_revised_item_tbl(l_row_cnt).use_up_plan_name :=null;
END IF;
IF l_transaction_type = 'UPDATE' THEN
FOR v_component in (SELECT * from eng_revised_items where change_notice = 'IK-API0000') LOOP
l_revised_item_tbl(l_row_cnt).eco_name := l_eco_name;
l_revised_item_tbl(l_row_cnt).organization_code := l_org_code;
l_revised_item_tbl(l_row_cnt).revised_item_name := l_rev_item_number1;
l_revised_item_tbl(l_row_cnt).new_revised_item_revision := '-A0';
l_revised_item_tbl(l_row_cnt).New_Revised_Item_Rev_Desc := '-F0 ik added';
l_revised_item_tbl(l_row_cnt).Updated_Revised_Item_Revision := '-F0';
l_revised_item_tbl(l_row_cnt).Start_Effective_Date := l_eff_date;
l_revised_item_tbl(l_row_cnt).New_Effective_Date := l_eff_date;
l_revised_item_tbl(l_row_cnt).Alternate_Bom_Code := v_component.alternate_bom_designator;
l_revised_item_tbl(l_row_cnt).Status_Type := v_component.status_type;
l_revised_item_tbl(l_row_cnt).Mrp_Active := v_component.Mrp_Active;
l_revised_item_tbl(l_row_cnt).Earliest_Effective_Date := sysdate;
l_revised_item_tbl(l_row_cnt).Requestor := '';
l_revised_item_tbl(l_row_cnt).Use_Up_Plan_Name := v_component.Use_Up_Plan_Name;
l_revised_item_tbl(l_row_cnt).Disposition_Type := v_component.Disposition_Type;
l_revised_item_tbl(l_row_cnt).Update_Wip := v_component.Update_Wip;
l_revised_item_tbl(l_row_cnt).Cancel_Comments := v_component.Cancel_Comments;
l_revised_item_tbl(l_row_cnt).Change_Description := 'TESTING ';
l_revised_item_tbl(l_row_cnt).Attribute_category := v_component.Attribute_category;
l_revised_item_tbl(l_row_cnt).Attribute1 := v_component.Attribute1;
l_revised_item_tbl(l_row_cnt).Attribute2 := v_component.Attribute2;
l_revised_item_tbl(l_row_cnt).Attribute3 := v_component.Attribute3;
l_revised_item_tbl(l_row_cnt).Attribute4 := v_component.Attribute4;
l_revised_item_tbl(l_row_cnt).Attribute5 := v_component.Attribute5;
l_revised_item_tbl(l_row_cnt).Attribute6 := v_component.Attribute6;
l_revised_item_tbl(l_row_cnt).Attribute7 := v_component.Attribute7;
l_revised_item_tbl(l_row_cnt).Attribute8 := v_component.Attribute8;
l_revised_item_tbl(l_row_cnt).Attribute9 := v_component.Attribute9;
l_revised_item_tbl(l_row_cnt).Attribute10 := v_component.Attribute10;
l_revised_item_tbl(l_row_cnt).Attribute11 := v_component.Attribute11;
l_revised_item_tbl(l_row_cnt).Attribute12 := v_component.Attribute12;
l_revised_item_tbl(l_row_cnt).Attribute13 := v_component.Attribute13;
l_revised_item_tbl(l_row_cnt).Attribute14 := v_component.Attribute14;
l_revised_item_tbl(l_row_cnt).Attribute15 := v_component.Attribute15;
l_revised_item_tbl(l_row_cnt).From_End_Item_Unit_Number := v_component.From_End_Item_Unit_Number;
l_revised_item_tbl(l_row_cnt).New_From_End_Item_Unit_Number := '';
l_revised_item_tbl(l_row_cnt).Original_System_Reference :=v_component.Original_System_Reference;
l_revised_item_tbl(l_row_cnt).Return_Status := '';
l_revised_item_tbl(l_row_cnt).Transaction_Type := l_transaction_type;
-- L1, the following is added for ECO enhancement
l_revised_item_tbl(l_row_cnt).From_Work_Order := '';
l_revised_item_tbl(l_row_cnt).To_Work_Order := '';
l_revised_item_tbl(l_row_cnt).From_Cumulative_Quantity := v_component.from_cum_qty;
l_revised_item_tbl(l_row_cnt).Lot_Number := v_component.Lot_Number;
l_revised_item_tbl(l_row_cnt).Completion_Subinventory := v_component.Completion_Subinventory;
l_revised_item_tbl(l_row_cnt).Completion_Location_Name :='';
l_revised_item_tbl(l_row_cnt).Priority := v_component.Priority;
l_revised_item_tbl(l_row_cnt).Ctp_Flag := v_component.Ctp_Flag;
l_revised_item_tbl(l_row_cnt).New_Routing_Revision := v_component.New_Routing_Revision;
l_revised_item_tbl(l_row_cnt).Updated_Routing_Revision := '';
l_revised_item_tbl(l_row_cnt).Routing_Comment := v_component.Routing_Comment;
-- L1, the above is added for ECO enhancement
l_revised_item_tbl(l_row_cnt).Eco_For_Production := v_component.Eco_For_Production;
END LOOP;
END IF;
Eng_Eco_PUB.Process_Eco( p_api_version_number => 1.0
, p_init_msg_list => FALSE
, x_return_status => l_return_status
, x_msg_count => l_msg_count
, p_bo_identifier => 'ECO'
, p_eco_rec => l_eco_rec
, p_eco_revision_tbl => l_eco_revision_tbl
, p_revised_item_tbl => l_revised_item_tbl
, p_rev_component_tbl => l_rev_component_tbl
, p_ref_designator_tbl => l_ref_designator_tbl
, p_sub_component_tbl => l_sub_component_tbl
, p_rev_operation_tbl => l_rev_operation_tbl
, p_rev_op_resource_tbl => l_rev_op_resource_tbl
, p_rev_sub_resource_tbl => l_rev_sub_resource_tbl
, x_eco_rec => x_eco_rec
, x_eco_revision_tbl => x_eco_revision_tbl
, x_revised_item_tbl => x_revised_item_tbl
, x_rev_component_tbl => x_rev_component_tbl
, x_ref_designator_tbl => x_ref_designator_tbl
, x_sub_component_tbl => x_sub_component_tbl
, x_rev_operation_tbl => x_rev_operation_tbl
, x_rev_op_resource_tbl => x_rev_op_resource_tbl
, x_rev_sub_resource_tbl => x_rev_sub_resource_tbl
, p_debug => 'N'
, p_output_dir => l_output_dir
, p_debug_filename => l_debug_filename
dbms_output.put_line('after API call');
DBMS_OUTPUT.PUT_LINE('=======================================================');
DBMS_OUTPUT.PUT_LINE('=======================================================');
DBMS_OUTPUT.PUT_LINE('Return Status: '||l_return_status);
dbms_output.put_line('x_eco_rec.eco_name:'|| x_eco_rec.eco_name );
dbms_output.put_line('x_eco_rec.org_code:'|| x_eco_rec.organization_code);
IF (l_return_status = 'E') THEN
dbms_output.put_line('x_msg_count:' || l_msg_count);
Error_Handler.GET_MESSAGE_LIST(x_message_list => l_error_table);
DBMS_OUTPUT.PUT_LINE('Error Message Count :'||l_error_table.COUNT);
FOR i IN 1..l_error_table.COUNT LOOP
--DBMS_OUTPUT.PUT_LINE(to_char(i)||':'||l_error_table(i).entity_index||':'||l_error_table(i).table_name);
DBMS_OUTPUT.PUT_LINE(to_char(i)||':'||l_error_table(i).entity_index||':');
DBMS_OUTPUT.PUT_LINE(to_char(i)||':'||substr(l_error_table(i).message_text,1,250));
END LOOP;
--ROLLBACK;
ELSE
DBMS_OUTPUT.PUT_LINE('==COMMITING==');
--COMMIT;
END IF;
DBMS_OUTPUT.PUT_LINE('=======================================================');
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('Exception Occured :');
DBMS_OUTPUT.PUT_LINE(SQLCODE ||':'||SQLERRM);
DBMS_OUTPUT.PUT_LINE('=======================================================');
RAISE;
END; -
Error while posting the Idoc 'Update error, transaction VA01'
Hi Gurus,
When an inbound Idoc for sales order is trying to post we are getting the error 'Update error, transaction VA01'.
Aslo following are the details of the error:
Update error, transaction VA01
Message no. 00377
Diagnosis
An error occurred in CALL TRANSACTION USING or CALL DIALOG USING
during a synchronous update.
The error was caused by the transaction VA01.
Update information
Return code: 009
Text : Error during insert table FPLTC (RC= 1, Key= )
Procedure
Pleas analyse your Batch-Input data.
You can also examine your posting data using the transaction SM13.
Can somebody let me know what would be the cause.
Also the we are trying to post the Idoc with a Id which is having maximum Authorization.Hi,
Where you able to resolve your issue, I would appreciate if you can share the solution.
Thanks -
Problem in CRM_ORDER_MAINTAIN for updating qty in more than 1 line item .
Hi abapers,
I am using BAPI CRM_ORDER_MAINTAIN to update quantity. Its updating the quantity properly if there is single line item for a transaction .If more than 1 line item is there then its throwing an exception* "Document is being distributed - changes are not possible"*.
Scenario:
I have a itab which is having 2 line items for a transaction. i run a loop pass the pass the required parameters in CRM_ORDER_MAINTAIN ,do CRM_ORDER_SAVE , BAPI_TRANSACTION_COMMIT for the 1st line item. When i run the 2nd loop, in CRM_ORDER_MAINTAIN it gives an exception saying NO_CHANGE_ALLOWED for the same transactions 2nd line item. leaving the quantity unchanged for both the line items. What may be the problem?
Note: We cannot say how many line items are there for an transaction. so no chance of grouping all items at a time and saving at a time.
Regards,
NavinHi Navin,
Why its not possible to use CRM_ORDER_SAVE only once. I think its possible. Call CRM_ORDER_MAINTAIN in loop for all the line item in transaction and after that call CRM_ORDER_SAVE once. Pls follow the below sample code.
loop at it_item.
call CRM_ORDER_MAINTAIN. (Here append data for all the line items and miantin the transaction).
emdloop.
After endloop call CRM_ORDER_SAVE. Also you can add some wait after CRM_ORDER_SAVE, In order to avoid locking issue.
PLs let me know where you are trying to use CRM_ORDER_MAINATIAN ? In any BADI or Z program ?
Regards,
Amol. -
User Exit or BADI for Updating Tax code (MWSKZ) using ME21N
Hi all,
I am trying to fin out an exit or badi for Updating Tax code (MWSKZ) and Unit of Measure in transaction ME21n.
The scenario is like this...
For Purchase Orders Tax code will be defaulted from Purchasing info record or contract or parameter id for that item-vendor-plant.
If the Tax Code is not defaulted and account assignment is blank then tax code on the PO is updated according to the below mentioned table
Table
Supplying Plant/ Receiving Plant Tax code
Vendor/Country
Any plant/vendor/
country 5050(NA) 20
2300 6700 E0
If the tax code on PO cannot be updated by the above table, then buyer needs to put tax code on the purchase order manually.
Thanks,
Shiva, BangaloreHi Siva.,.,.,
These r the exits.,..,which will be called while calling ME21N/ME22N/ME23N
EXIT_SAPMM06E_006
EXIT_SAPMM06E_007
EXIT_SAPMM06E_008
EXIT_SAPMM06E_009
EXIT_SAPMM06E_012
EXIT_SAPMM06E_013
EXIT_SAPMM06E_014
EXIT_SAPMM06E_016
EXIT_SAPMM06E_017
EXIT_SAPMM06E_018
U want to default some values while the Initial screen will come right,
while u Enter ME21N in command Prompt.,.,two exits will get triggerd,
EXIT_SAPMM06E_014
EXIT_SAPMM06E_016
If u want to Default some values u can use these two exits.,.
Try using EXIT_SAPMM06E_016.,.this will solve ur purpose.
and if the user changes some values on screen.,,and you want them to get reflected .,.,.that means if user changes and saves data .,.
While saving.,.,EXIT_SAPMM06E_012 and EXIT_SAPMM06E_013 will get triggerd
Try using EXIT_SAPMM06E_013.,,.it was somehow the same requirement as mine.,.,IN my case it worked fine.,.,
Regards
Debasish
Message was edited by:
Debasish Das -
BADI-User exit required for updating Purchase order header field -IHREZ
Hello All,
We have requirement in our business to update the purchase order header field "our reference" EKKO-IHREZ with some text field. We need a BADI/user exit that can be used for updating this field . We have checked the BADI ME_PROCESS_PO_CUST and unfortunately we are not able to use this BADI as it getting triggered in enjoy SAP transactions ME21N , ME22N etc. We are not creating the purchase order manually and we are using ME59N for creating Purchase order . Hence we are looking for some user exit/BADI that can be used in ME59N for updating the purchase order header field IHREZ.
Thanks in advance for your immediate response .
With regards,
Joseph Anand BTRY using the exist u2022 EXIT_SAPLME59_001
You can also later on add this field by BAPI_PO_CHANGE -
[Solved] if(Transaction specified for a non-transactional database) then
I am getting started with BDBXML 2.4.14 transactions and XQuery update functionality and I am having some difficulty with 'node insert ...' and transactions failing with 'Transaction specified for a non-transactional database'
Thanks for helping out.
Setup:
I have coded up a singleton manager for the XmlManger with a ThreadLocal holding the transaction and a query method to execute XQueries. The setup goes like this:
environmentConfig = new EnvironmentConfig();
environmentConfig.setRunRecovery(true); environmentConfig.setTransactional(true); environmentConfig.setAllowCreate(true); environmentConfig.setRunRecovery(true); environmentConfig.setInitializeCache(true); environmentConfig.setTxnMaxActive(0); environmentConfig.setInitializeLocking(true); environmentConfig.setInitializeLogging(true); environmentConfig.setErrorStream(System.err);
environmentConfig.setLockDetectMode(LockDetectMode.MINWRITE); environmentConfig.setJoinEnvironment(true); environmentConfig.setThreaded(true);
xmlManagerConfig = new XmlManagerConfig(); xmlManagerConfig.setAdoptEnvironment(true); xmlManagerConfig.setAllowAutoOpen(true); xmlManagerConfig.setAllowExternalAccess(true);
xmlContainerConfig = new XmlContainerConfig(); xmlContainerConfig.setAllowValidation(false); xmlContainerConfig.setIndexNodes(true); xmlContainerConfig.setNodeContainer(true);
// initialize
instance.xmlManager = new XmlManager(instance.getEnvironment(), instance.getXmlManagerConfig());
instance.xmlContainer = instance.xmlManager.openContainer( containerName, instance.getXmlContainerConfig());
private ThreadLocal<XmlTransaction> transaction = new ThreadLocal<XmlTransaction>();
public XmlTransaction getTransaction() throws Exception {
if (transaction.get() == null) {
XmlTransaction t = xmlManager.createTransaction();
log.info("Transaction created, id: " + t.getTransaction().getId());
transaction.set(t);
} else if (log.isDebugEnabled()) {
log.debug("Reusing transaction, id: "
+ transaction.get().getTransaction().getId());
return transaction.get();
private XmlQueryContext createQueryContext(String docName) throws Exception {
XmlQueryContext context = xmlManager.createQueryContext(
XmlQueryContext.LiveValues, XmlQueryContext.Lazy);
List<NamespacePrefix> namespacePrefixs = documentPrefixes.get(docName);
// declare ddi namespaces
for (NamespacePrefix namespacePrefix : namespacePrefixs) {
context.setNamespace(namespacePrefix.getPrefix(), namespacePrefix
.getNamespace());
return context;
public XmlResults xQuery(String query) throws Exception {
XmlQueryExpression xmlQueryExpression = null;
XmlQueryContext xmlQueryContext = getQueryContext(docName);
try {
xmlQueryExpression = xmlManager.prepare(getTransaction(), query,
xmlQueryContext);
log.info(query.toString());
} catch (Exception e) {
if (xmlQueryContext != null) {
xmlQueryContext.delete();
throw new DDIFtpException("Error prepare query: " + query, e);
XmlResults rs = null;
try {
rs = xmlQueryExpression.execute(getTransaction(), xmlQueryContext);
// catch deadlock and implement retry
catch (Exception e) {
throw new DDIFtpException("Error on query execute of: " + query, e);
} finally {
if (xmlQueryContext != null) {
xmlQueryContext.delete();
xmlQueryExpression.delete();
return rs;
<?xml version="1.0" encoding="UTF-8"?>
<Test version="0.1">
<Project id="test-project" agency="dda">
<File id="large-doc.xml" type="ddi"/>
<File id="complex-doc.xml" type="ddi"/>
</Project>
<Project id="2nd-project" agency="test.org"/>
</Test>
Problem:
All the queries are run through the xQuery method and I do delete the XmlResults afterwards. How do I get around the 'Transaction specified for a non-transactional database' what is the transactions doing? How do I get state information out of a transaction? What am I doing wrong here?
1 First I insert a node:
Transaction created, id: -2147483647
Adding document: large-doc.xml to xml container
Reusing transaction, id: -2147483647
Working doc: ddieditor.xml
Root element: Test
Reusing transaction, id: -2147483647
insert nodes <Project id="JUnitTest" agency="test.org"></Project> into doc("dbxml:/ddieditor.dbxml/ddieditor.xml")/Test
Reusing transaction, id: -2147483647
2 Then do a query:
Reusing transaction, id: -2147483647
doc("dbxml:/ddieditor.dbxml/ddieditor.xml")/Test/Project/@id
Reusing transaction, id: -2147483647
3 The same query again:
Reusing transaction, id: -2147483647
doc("dbxml:/ddieditor.dbxml/ddieditor.xml")/Test/Project/@id
Reusing transaction, id: -2147483647
4 Delete a node:
Reusing transaction, id: -2147483647
delete node for $x in doc("dbxml:/ddieditor.dbxml/ddieditor.xml")/Test/Project where $x/@id = '2nd-project' return $x
Reusing transaction, id: -2147483647
5 Then an error on query:
Reusing transaction, id: -2147483647
doc("dbxml:/ddieditor.dbxml/ddieditor.xml")/Test/Project/@id
Reusing transaction, id: -2147483647
Transaction specified for a non-transactional database
com.sleepycat.dbxml.XmlException: Error: Invalid argument, errcode = DATABASE_ERROR
at com.sleepycat.dbxml.dbxml_javaJNI.XmlResults_hasNext(Native Method)
at com.sleepycat.dbxml.XmlResults.hasNext(XmlResults.java:136)
Message was edited by:
jannikjOk got it solved by increasing the locks lockers and mutex's I allso increased the the log buffer size:
environmentConfig = new EnvironmentConfig();
// general environment
environmentConfig.setAllowCreate(true);
environmentConfig.setRunRecovery(true); // light recovery on startup
//environmentConfig.setRunFatalRecovery(true); // heavy recovery on startup
environmentConfig.setJoinEnvironment(true); // reuse of environment: ok
environmentConfig.setThreaded(true);
// log subsystem
environmentConfig.setInitializeLogging(true);
environmentConfig.setLogAutoRemove(true);
environmentConfig.setLogBufferSize(128 * 1024); // default 32KB
environmentConfig.setInitializeCache(true); // shared memory region
environmentConfig.setCacheSize(2500 * 1024 * 1024); // 250MB cache
// transaction
environmentConfig.setTransactional(true);
environmentConfig.setTxnMaxActive(0); // live forever, no timeout
// locking subsystem
environmentConfig.setInitializeLocking(true);
environmentConfig.setMutexIncrement(22);
environmentConfig.setMaxMutexes(200000);
environmentConfig.setMaxLockers(200000);
environmentConfig.setMaxLockObjects(200000); // default 1000
environmentConfig.setMaxLocks(200000);
// deadlock detection
environmentConfig.setLockDetectMode(LockDetectMode.MINWRITE);
In the docs by Oracle it is limited information given regarding the impact of these settings and their options. Can you guys point in a direction where I can find some written answers or it hands on? -
Hi,
If you are using Forte as 2-tier tools, there shouldn't be any problem in
using select ... for update. The sql is actually passed through to your
back-end database. So everything should work the same, provided that every
user has his own database session ( like by using DBResourceMgr to create
DBSession at run-time for each user. )
However, if you are building multi-tier application, there is no simple
answer to your question. The problem is common to all 3-tier application
since the application / database layer is shared among many users. If you
start a transaction from client side, use select ... for update to lock a
record, allow user to change data, then update and end the transaction, you
are not just locking up a record, but also a database session. In such
model, you will run out of DBSession very soon.
What we did here is to use a "lock count", which exists is every table.
When client retrieves a record, it won't start a transaction there. A
transaction is started only on the server and after client commits its
changes to the server. Data consistency is checked by checking the lock
count in the update where clause.
It looks dumb, but it's the only solution that we can reach after consulting
a lot of white paper and Forte consultants. Moreover, Forte consultant also
said its bad to start a transaction on client side.
I do hope that there is a better solution out there in handling 3-tier
applications too. Afterall, this lock count thing is clumsy.
Peter Sham.
-----Original Message-----
From: Phong Tran [SMTP:[email protected]]
Sent: Thursday, March 18, 1999 6:50 AM
To: [email protected]
Subject: for update clause
dear forte-users,
I notice the "for update" clause can only used with cursor.
Just wonder why you can not use it with "sql select ...." statement.
Also as I understand it, one way to protect the data consistency is
through
the mutex lock but then you turn the object to a single-threaded to
serialize access even though you access different rows in a
database
table. The fact is you only want access on a particular row.
Does anyone know the best way to lock a row (or rows) in the
database ?
If you have to rely on the "for update" clause in the cursor
definition for
the locking, then you almost end up with a lot of cursors.
Example: the method ReadnWriteDB(ordeId) accesses a specific row
but since the orderOBj serializes access, other tasks have to wait.
OrderObj: OrderMgr = new(IsShared = TRUE, IsTransactional = TRUE);
method GetOrderInfo() of the TransactionSO.
begin transaction
OrderObj.ReadnWriteDB(orderId);
end transaction;
From Client:
Begin
start task TransactionSO.GetOrderInfo(orderId);
end;
Phong
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Which application front end are you using.
Also, you'll get the same error if your Query runs too long, and/or your rollbacks are too small.
Maybe you are looking for
-
Total newbie i have drawn some shapes and want to colour them
Hi i have drawn some basic shapes and want to colour them i have watched a tutorial but must be doing something wrong. I highlight the shap with my selection tool then click on the fill button, choose a colour then click ok and nothing happens, what
-
STORE A COMPLETE FILE SYSTEM IN THE DATABASE 11GR2
Hi everyone I have the following issue: I tried to store in an oracle database TABLE the completre file structure of a file system that includes the follwing: -Name of the file -Date of last modification -Location -The entire content of the phisical
-
Apple tv just started showing I need to connect to itunes.
I can't as I do not have the cable needed. What can I do?
-
Hi Gurs, I am creating RFQ with reference to PR for Vendor Consignment Stock(i.e. Item Category as 'K'), i am getting an error as Field selection PT2A not defined . Can any one can guide me why i am getting this error. Thanks in advance.. Regards Jay
-
Can you get 3G for an Ipod touch 4
can you get 3G for an Ipod touch 4