As a general statement, want you are doing is not something you want to experiment with unless you have a completely separate development machine to work with that you can refresh if you mess it up. You need to have a much better understanding of the file structure used by your application before proceeding further.
See additional responses below: > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Brutzman, Bill > Sent: Monday, August 08, 2005 3:34 PM > To: 'u2-users@listserver.u2ug.org' > Subject: RE: [U2] New UV Accout VOC > > [1] An example Q Pointer would help. It seems the downside to using > Q-Pointers is that we > would need a few hundred of them. On the other hand, for a SAND-BOX, > the Q-Pointers could > be added as needed. You miss-understand me. When you copied the VOC from another account it may have/probably contained Q-pointers that were valid for the production account. For example if you have a CORPORATE account with a file called GL there might have been a pointer that looked like: Q CORPORATE GL This would be potentially disastrous in your SANDBOX account as any writes performed to GL would up the live account. You should NEVER have a Q-pointer to a application file in the production/live account(s). In this scenario you would want to also create a SANDBOX-CORPORATE that is a copy of CORPORATE and change the Q-pointer in your. > > [2] I copied NEWACC to NEWACC.BAK and then overwrote NEWACC with VOC and > then ran > UPDATE.ACCOUNT. Doing so did not work. A message came back saying... > "The following records appear in NEWACC but not in VOC." Of course, > these well > all of the records that we need. > I am not sure what you are trying to accomplish here. The NEWACC file is the repository for UV to keep the VOC entries it needs/wants in a clean account. Basically, you should NOT be doing what you did. As I said before my preferred method is to copy the account at the OS level then do an UPDATE.ACCOUNT to be sure the UV entries are correct for the development system. Alternatively you could have setup a new account, which would already have a clean VOC install. Then create a Q-pointer to the other VOC file and copy the entries from the Q-pointer with NO OVERWRITE. If there are any conflicts make a note of them and deal with them manually. > [3] While our baseline ERP system is from www.GRMS.com, most of what we > use > is homegrown. > I am not familiar with them so I can't help there. > [4] Copies of VOC appear in half a dozen different places. When I change > VOC in our baseline > system, I can see the date change on the HP-Ux side. I was hoping > that > the only VOC that > matters is the one under the account itself. > Again, this is dependant on the application. If you are not familiar with the account structure this software you should contact your vendor before attempting something like this!!! > [5] I am unable to get change directories to get to > /u2/METAL/&TEMP&/NEWACC > and > > /u2/SANDBOX/&TEMP&/NEWACC to try the above > procedure. > > [6] Somehow our production system knows that the compiled code lives > here.... > > /u2/METAL/SOFTWARE/ACC.BP Accounting Code > /PUR.BP Purchasing Code > ... /etc etc > > while the data files are in... > > /u2/METAL/* > > Further suggestions would be appreciated. > > Thanks to those who responded... > > --Bill Brutzman > Manager, IT > HK MetalCraft Mfg Corp > PO Box 775 > 35 Industrial Road > Lodi NJ 07644-0775 > > [EMAIL PROTECTED] > > 973.471.7770 x145 .voice > 973.471.9666 .fax Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
