[AD] If I don't put this here, someone might complain... Our tools for going MV to SQL do exactly that. We have a mapping wizard that analyzes the dictionaries and the data. Depending on how good the dictionaries are, we get close to 80% right first try. Then you get to test and tweak, all in a graphical environment, until you have it 100% right. The tool lets you even decide what %age of bad data you'll ignore. It's not uncommon to have a handful of bad records in a big file. Set the tolerance to 1% and if you have a dictionary that says attribute 2 is a date, provided less than 1 in 100 items have something that's not a valid date (you can set the range of values that work for your system, too) we'll call it a date and use that dictionary for the field name.
We also have tools that let you identify bad records so you can actually find and fix them. The map is ultimately stored in the file's dictionary. I think we've gotten off-topic, again, though. The original question was about going the other way. Going SQL to MV, Item-id selection is likely to be the biggest hurdle. You do not need to set a primary key in SQL Server. Even if you do, you may have a unique index in SQL which would make a better candidate for the item-id. A tool to migrate can make a best first guess, but it will sometimes get it wrong. At some point, someone familiar with the application, with an architectural mindset, is going to have to look at the output and probably tweak the results. I just don't see a substitute for this. On the other hand, if you just get the data over, someone can convert it locally to whatever format they ultimately want. Our tools typically exist to help get the data to where the application programmers are, and they take it from there. Then the application guys figure out what to do with it from there. If you have to repeat this from time to time, you use a staging approach; you pass the raw converted data to a temporary file, then the application people process this file and convert it to their ultimate format. So, you get to choose between doing it all on the first pass, or getting the data over and letting someone at the target end (in this case, MV) complete the transformation. You are choosing between "E -> TL" and "ET -> L". Where T happens is often driven by where the programming muscle in the project resides. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marc Harbeson Sent: Tuesday, December 28, 2010 8:13 AM To: 'U2 Users List' Subject: Re: [U2] Migration LOL In my mind - there would be a operator map tool here - I don't think the tool could be self aware enough to figure out every possible combination of everything. It could certainly "guess" 80% correctly and be corrected on the remaining 20% on suggesting maps. I see this with data going from MV to SQL - sometimes the dictionaries are just wrong... it's easier to adjust using the map... (in particular if they're not your dictionaries to adjust) I would imagine an adjustment could be made to the maps to increase MV performance - just like you would in SQL when porting MV data there. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Houben Sent: Friday, December 24, 2010 1:41 AM To: U2 Users List Subject: Re: [U2] Migration Oh, one more point. What if your SQL environment had NOT defined a primary key for APPOINTMENTS, but had multiple indexes, one of which happened to have CUSTOMERNO, APPTDATE, APPTTIME and APPTTYPE. How would you figure out what to use as the item-id of the PICK file? What if you had a SQL table that actually did not have a set of fields that guaranteed a unique value? Then you have NOTHING to create an item-id from! I have to stop this, it will consume me! :o But the list goes on. Oh the humanity! _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
