Hey Kebbon, I've done this before and basically what the diff is between sql and mv is the mv's.
So let's say you have an order, and on that order are order lines. sql will only be able to handle the single value data from the order and that would go into one ascii file. The order lines would need to be broken down into their own records in a separate file. The first field of each line would be order*line.nbr, and then the rest of the single value info for that line would be the rest of the record - tab delimited. If there was multiple delivery data for each line in a sub-valued-group, that too would then need to be broken down into it's own file with the first field being order*line*delivery. When this gets sucked up into SQL the first field becomes the index that points to a record number in a file where the rest of the data is. Good old ISAM....(stinky old ISAM actually) What I did was to write a program that would analyze the dicts for each file and pull them into groups of groups using the associated field (this was on a database where the dicts where actually maintained specifically so it would be SQL compliant). Then after manually reviewing this document with the conversion team, we'd decide which fields were needed and I would then tweak the output from the groups of groups file setting flag to note it needed to be included and what order it was to be in - like if it was to be the third field then I'd put in a 3, even though it might have been the attr in the original file. Then run another program that would build the INCLUDES for the fields that were needed and then stick that into a skeleton program, and run another program to tweak the file names in the skeleton program so it would be specific to the file being downloaded and in the order desired. This allowed me to only write a few programs, so that once the decision was made as to what fields to include and their order, I just had to do a little data entry, run a few routines and bingo, download completed. Even so it took months to go through the motions to create all the programs. Since they were in their own library, I then wrote a program that would read that library and execute all the programs in sequence so that on the cutoff date the operator wouldn't be able to forget anything. It was a lot more work for the guys on the SQL side. Three guys had to be hired to put all the stuff into the SQL files that I was creating from the MV side. So much for *upgrading* their database. You'd think they would have gotten a clue that they were spending three times as much to convert TO the new database as it took to convert FROM the old database, but no..... hth, Allen E. Elwood www.tortillafc.com Quality Code Since 1978 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kebbon Irwin Sent: Wednesday, July 30, 2008 10:44 To: [email protected] Subject: [U2] SAP Migration We have a client that has been purchased by another company and they run SAP. We have been asked to assist in the migration process and to provide specific data in "both Excel and SQL format". I must confess, I am not sure what they mean by "SQL format". Is there a standard layout I should be aware of? TIA Kebbon ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
