Re: \'Lock\' process for F4211 records
There's a software update (SAR) for this problem.
The fact is, it's not only that you can't check in P4210,
but any hugh objects can't be checked in. To play safe,
make sure you have 'Keep check out' checked, when
you check in.
Boris
----- Original Message -----
From: "Joseph_Sadler" <
[email protected]>
To: <
[email protected]>
Sent: Tuesday, October 31, 2000 9:38 PM
Subject: Re: 'Lock' process for F4211 records ~~221:227
>
> Just a word of caution.
> Unless you have at least B73.3.2 with Service Pack 11.3, (possibly SP 10),
> you will not be able to Check In P4211 or P4310 after you make your
> modifications.
> We learned this the hard way. We checked out the application, made mods,
> and then checked it back in. The check in failed and we lost two weeks of
> mods.
> Unfortunately, OneWorld gave no indication that anything was wrong. Even
> the
> deployment appeared OK, and the Install Log said "Congratulations!"
>
> Using the Universal Table Browser, (UTB), it was verified that there was
no
> record in table F98750, (data source: Central Objects CRPB733 ), for
> application P4211 or P4310. This observation confirmed that the "Check In"
> procedure did not complete successfully.
>
> RE: DWIGHT A. PAUL, III
> OneWorld Technical Consultant
> Global Customer Solutions: Americas
> One Technology Way
> Denver, CO 80237
>
> Phone: 1-800-289-2999
> Fax: 303-334-3005
> E-mail:
[email protected]
>
> The following is documentation for the SAR that was opened for various
> versions
> of B733 that encountered the same issue and strongly supports moving your
> client from their current service pack to Service Pack 11.3 where the same
> error has not
> occurred.
>
> A ORIGINAL REQUEST
>
> The Check-in of a large object fails when checking into a new path code
> (thus causing a large amount of inserts). This can be duplicated by
> checking in P4210 into a new path code. This causes approximately 11,500
> inserts in a single transaction.
>
> B FINAL DISPOSITION
>
> The problem is that the logging fails before committing the transaction,
> and it causes rolling back of the transaction. Fix the logging problem and
> the transaction will be committed OK.
>
> C MEMBERS AFFECTED MEMBER SRCLIB OBJLIB
>
> B7332_SP9_SHD/system/jdekrnl/transmon/ JTP_TPC.C
> B7332_SP9_SHD/system/jdekrnl/transmon/ JTP_LM.C
> Rights given 1/19/00 mkl
> O CONNECTED SAR NUMBERS
>
> duplicated SAR from 3415535 (SPL) 3415535
> B733 SP 10 3556961
> BDEV (C9) 3398202
> B733_SP7_OBJ (Exactly the same) 3582991
> B733 SP 7.1 3556928
> B733 SP7_HOPP 3613005
> B733_SP7_SHL 3634391
> B733_sp9_KEN 3635255
>
> Z FIRST INCLUDED IN UPDATE RELEASE ID UPDATE DATE INCL.
>
> B7332_SP9_SHD/system/jdekrnl/transmon/
>
> The real issue is not about committing a transaction, it is a logging
> problem. One of the logging functions fails while logging a large amount
of
> transaction message multiple times. That causes rolling back the
> transaction. An additional problem found is that the log file is not
> removed even if the transaction is committed OK. Both of them are fixed
and
> the code changes were reviewed by Chanuee Pansuvan and Maneesh Gupta.
> Youping Hu x4-2442 9/17/99
> ..
> B733 SP7 has the same problem. Youping Hu 11/11/99.
> ..
> The same change is made for B7332_SP9_SHD.
>
> <<...>> Larry W. Hataway Jr.
> Technical Consultant
> One World Diagnostics & Problem Isolation
>
> Here are a few of the SARs I found on the issue.
> · 3415535
> · 3820206
> · 362002
>
> It would appear that Service Pack 10, (SP10), addresses the issue.
> Apparently since the application is so large there is an error in logging
> and this causes the changes to be rolled back.
>
> NOTE:
> Make sure that all applications, and UBEs, are checked in prior to
> Re-Installing OneWorld on any local PCs. The re-install will wipe out
> any FDA spec records, etc..
>
>
>
>
> Alexandra_Lazar
> <Alexandra_Lazar@cain-assoc To:
[email protected]
> iates.com> cc:
> Sent by: Subject: 'Lock'
process for F4211 records
> ~~0:221
>
[email protected]
> m
>
> 10/30/00 07:54
> PM
> Please respond
> to jdeowdev
>
>
>
>
>
>
> Hello List,
>
> One of our clients has a requirement to 'block' the ENTIRE order from
> advancing to the next status while it is in the middle of order entry,
> ship/confirm, etc. The main problem is that the users do entry of the
> partial order, save it and then go back into it. During ship/confirm,
> they confirm one line at a time (staying on the ship/confirm screen) and
> want to prevent the generation of a packing slip until the user is
> completely out of the order. We were thinking about using one of the
> available fields in F4211 as a 'lock' field and modify the required
> programs to exclude records with a 'lock' on.
>
> Any ideas or comments would be greatly appreciated.
>
>
>
>
> --------------------------
> To view this thread, visit the JDEList forum at:
>
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OWDEV&Numb
er=221
>
> *************************************************************
> This is the JDEList One World Developers Mailing List.
> Archives and information on how to SUBSCRIBE, and
> UNSUBSCRIBE can be found at
http://www.JDELIST.com
> *************************************************************
>
>
>
>
>
>
>
> --------------------------
> To view this thread, visit the JDEList forum at:
>
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OWDEV&Numb
er=227
> *************************************************************
> This is the JDEList One World Developers Mailing List.
> Archives and information on how to SUBSCRIBE, and
> UNSUBSCRIBE can be found at
http://www.JDELIST.com
> *************************************************************
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
