We will gladly adopt early for you :) On Mon, Aug 27, 2012 at 6:01 PM, Susan Palmer <suzanpal...@gmail.com> wrote:
> ** Jason/Misi, > > Thanks for your interest. I already knew the answer but was hoping for > some 'miracle'. We just basically did the full build new dbs/servers last > year when we couldn't make our 7.01 to 7.5 upgrade work. It should be > noted that when using oracle you don't actually choose unicode in Remedy, > it installs based on how oracle is installed. Wish I had paid more > attention to that fact last year. > > Regarding the import of tables/objects, that was not a pleasant > experience. It changes all the table ID's which caused problems in other > applications using Remedy. Of course now we have a list of those, guess > they can be modified again. Hopefully they took my advice to use table > names not ID's. > > We have a freeze beginning in November during our customer's busy season > so we've basically run out of time this year. We'll tackle it next year > and since it's a total new install may consider ARS v8.0 right away, and > oracle 11g. I was looking at the compatibility chart regarding linux but > that seems a little confusing about using that and I haven't checked > further. We'd really like to move away from the oracle costs. > > We're also moving to a new location in April so I'm think we'll be > postponed until June/July which may work well with v8. Gives the early > adopters time to work out the kinks! > > Thanks again for your input ... > > Susan > > See you at RUG! > > On Mon, Aug 27, 2012 at 7:18 PM, Jason Miller <jason.mil...@gmail.com>wrote: > >> ** Hi Susan, >> >> I agree that what Misi describes is the best way to go about it. >> Admittedly I have never had to resolve this issue but it is consistent >> with the other Remedy data translation/transition scenarios. A while back >> I was talking to a Remedy admin who's DBA told him the DB was Unicode when >> it wasn't. He installed ARS as Unicode and some time later issues began to >> arise. BMC's recommendation was to build a new system with matching >> character sets and to export the data out of the broken system and import >> into the new system using the AR API (import tool, etc.). >> >> Jason >> >> >> On Sun, Aug 26, 2012 at 10:09 PM, Misi Mladoniczky <m...@rrr.se> wrote: >> >>> Hi Susan, >>> >>> Why not remove all complex manual thinking, guessing and planning? >>> >>> 1. Do a fresh install >>> 2. Export your def and import it the new system >>> 3. Copy your data using RRR|Chive >>> 4. Stop your users from accessing the servers, stop escalations, email >>> etc >>> 5. Do a final delta-transfer using RRR|Chive (~1 hour) >>> 6. Switch your users to the new server >>> >>> You might get data that does not fit into the new syst, if you have a lot >>> of 128+ ascii codes in your current data. But step 4 above can be run >>> multiple times, until you have corrected all errors. >>> >>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP >>> 2011) >>> >>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): >>> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. >>> Find these products, and many free tools and utilities, at http://rrr.se >>> . >>> >>> > Hi everyone, >>> > >>> > It seems my life is complicated this week. Again I need to draw on >>> your >>> > experiences and I'm looking for your opinions and cautionary >>> statements. >>> > >>> > Background: We use an outsourcer company to do the bulk of our >>> database >>> > work. When we built new servers last year and they build the new >>> oracle >>> > 10g databases we didn't notice that they were not Unicode. Apparently >>> the >>> > previous ones were, but in actuality we didn't really have a need for >>> it. >>> > About 5 years ago we opened a China office requiring all staff to be >>> > English proficient so everything was still ok. But now we're finding >>> that >>> > customer information which arrives in simplified Chinese, which they >>> > translate into English, which then needs to be re-translated back to >>> > Chinese to meet government requirements for billing is not as straight >>> > forward as it may sound. So they were trying to type more Chinese in >>> and >>> > of course since the new server databases were not Unicode it didn't >>> work >>> > like it did before. Then to add to the pain, no one said anything. >>> So >>> > here we are a year later and now it's a big deal. >>> > >>> > So, we are endeavoring to change to Unicode. Our approach is to >>> create a >>> > new server space, create a new Unicode database, and get the data in >>> there >>> > converted, and then install the application again. No upgrades of db >>> or >>> > application involved, only the Unicode aspect of it. >>> > >>> > Well, that sounds so much easier than it's turning out to be. Our dba >>> has >>> > run CSSCAN various times and finally came up with a list of >>> forms/fields >>> > that have potential problems with the conversion. The current field >>> > length >>> > is being totally used so in the conversion to Unicode it needs more >>> field >>> > length. The dba is suggesting that he just expand the database field >>> > lengths with no need to touch the form objects. This sets off all >>> sort of >>> > red flags for me. I never let anyone go directly to the database for >>> > data >>> > updates. Other applications we use can read data but if they need to >>> > write >>> > there they use the Remedy API. There can be no manipulation of the >>> tables >>> > in the database, it must all be done via developer tool. >>> > >>> > What else is troubling is that in the list of tables/fields that have a >>> > problem some tables/fields that should be listed because that's where >>> the >>> > data originated and was pushed down from are not listed. Many of the >>> > records in question are older and if some data gets 'cut off' or what I >>> > used to think truncated meant we can live with that. We're talking >>> > several >>> > thousand records in 15-25 tables. >>> > >>> > The dba is proposing the following: >>> > >>> > I will export the table metadata and data of the tables, listed in the >>> > spreadsheet with NLS_LANG set to AMERICAN_AMERICA.WE8ISO8895P1. >>> > >>> > I will then truncate the tables and drop the tables. >>> > >>> > The CSALTER program will then be ran against the database. >>> > >>> > I will then import the table metadata and data, using NLS_LANG set to >>> > AMERICAN_AMERICAN.AL32UTF8 >>> > >>> > >>> > >>> > This will cause the internal expansion of the column from bytes to >>> chars >>> > and some of the tables will fail to import because some of the >>> characters >>> > may take up to 3 bytes instead of 1. >>> > >>> > >>> > >>> > You said there would be a problem with the forms and I know what you >>> are >>> > saying. But if just the lengths of some of the columns change, will >>> that >>> > invalidate the forms? >>> > >>> > So if a column is defined VARCHAR2(50) in the database and the form and >>> > that column is enlarged to VARCHAR2(100) just in the database, will >>> that >>> > really affect the form? The data entered will be 50 Bytes long because >>> of >>> > the form but that data will be stored in a 100 byte column in the >>> > database. >>> > Is that a problem? >>> > >>> > >>> > >>> > So my questions are: Do you have any experience with this type of >>> > situation and how did you deal with it? What really were the pitfalls? >>> > >>> > >>> > >>> > I'm not even sure what other questions to ask. I only hope the above >>> > gives >>> > enough of the story without leaving out important details. >>> > >>> > >>> > >>> > Thanks for your help, >>> > >>> > Susan >>> > >>> > >>> > >>> > Susan Palmer >>> > >>> > ShopperTrak >>> > >>> > 200 W Monroe 11th Floor >>> > >>> > Chicago, IL 60606 >>> > >>> > 312-529-5325 >>> > >>> > spal...@shoppertrak.com >>> > >>> > >>> > >>> > ARS v7.5 >>> > >>> > Oracle 10g >>> > >>> > Sun Solaris >>> > >>> > >>> _______________________________________________________________________________ >>> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" >>> > >>> >>> >>> _______________________________________________________________________________ >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" >>> >> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >> > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
