Nancy Lytle
word_diva at hotmail.com
Fri Oct 28 09:44:26 CDT 2005
I have used Monarch in the past also, and you said it so well, its a real "Wonder", sometimes it is so cool I wonder how it works, and other times I couldn't figure out how to get it to do what I wanted, and I wondered how the h*ll it worked! Almost all the migration I have done has involved cleaning old data outside of Access (usually in Excel, as that is where most of the migration is coming from), linking or importing the old data into a database with the structure already in place, that part is usually phase one and is on one side of a form, with one button to push, that runs all the importing, then another button to run all the queries that manipulate the data and append it to the "new" structure tables, already set up to run in the needed order. The users I have dealt with prefer not to know (I do however document everything for them with a list of the order in which everything is run) but to just push a button or two and have everything done. Nancy Lytle N_Lytle at terpalum.umd.edu >From: John Colby <jwcolby at colbyconsulting.com> >Reply-To: Access Developers discussion and problem >solving<accessd at databaseadvisors.com> >To: "'Access Developers discussion and problem >solving'"<accessd at databaseadvisors.com> >Subject: Re: [AccessD] Is anyone migrating data? >Date: Fri, 28 Oct 2005 10:28:45 -0400 > >My client - DIS - uses monarch. It is really cool, nay amazing, and a PITA >at the same time. I have not been allowed at the keyboard so I can't say >exactly, but we were just unable to get some things to work the way we >needed, so the process is "do this in monarch", now go do this in Access. >And of course they are unwilling to buy the programming interface that >would >allow me to drive it from Access. > >John W. Colby >www.ColbyConsulting.com > >Contribute your unused CPU cycles to a good cause: >http://folding.stanford.edu/ > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim >Sent: Friday, October 28, 2005 10:20 AM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] Is anyone migrating data? > > >Monarch is great for extracting data from reports. It has an object model >that allows you to automate data extraction from inside Access. I do things >like download bank stmts from the internet and parse them into Access >tables. Jim Hale > >-----Original Message----- >From: Jim Dettman [mailto:jimdettman at earthlink.net] >Sent: Monday, September 26, 2005 8:59 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Is anyone migrating data? > > > > I've used Data Junction for years to do all my migration stuff. >Especially >for some of the stranger database formats. Good product. > >Jim. > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John Colby >Sent: Thursday, October 27, 2005 11:54 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Is anyone migrating data? > > >I am right in the middle of a data migration job. I am building a simple >two table (so far) tool to assist me in organizing the data migration. >This >will be a recurring migration, fairly complex. The client hired people to >build the system and get the data migrated once but that developer did not >document the process, nor save the queries etc. Thus I am having to learn >the whole process from scratch using the "sit with the client and ask >questions" method. They want it documented this time naturally. > >I have migrated many different databases over the years but mostly the >migrations were "one-shot" migrations designed to get the data from >denormalized tables in to a new system I was building to replace the old >system. In this case, the old system will stay (mostly) with the same data >having to be imported every month, or quarter - something like that. > >The tool is pretty simple, just a form to list the table names, in the >order >the tables need to be migrated, and some attributes to describe what that >step is doing, then a child table to hold the query / SQL statement / code >to run to migrate the data into that table. Anyone who has done this stuff >knows that the process is usually order sensitive in terms of which tables >get migrated when, and also the order that the queries are run for any >given >table. My objective is just to document the table / order / requirement / >data source, plus the queries / order used for each table, with comments. >In >the end I will have a little program that pulls each record and applies the >queries in the order they are in the table, such that the process is "push >button" (with luck) and the client can do it themselves. Documentation will >be in the comments in the table and can be pulled into a report. > >If anyone else is doing this kind of stuff and wishes to collaborate with >me, contact me offline. > >*********************************************************************** >The information transmitted is intended solely for the individual or entity >to which it is addressed and may contain confidential and/or privileged >material. Any review, retransmission, dissemination or other use of or >taking action in reliance upon this information by persons or entities >other >than the intended recipient is prohibited. If you have received this email >in error please contact the sender and delete the material from any >computer. As a recipient of this email, you are responsible for screening >its contents and the contents of any attachments for the presence of >viruses. No liability is accepted for any damages caused by any virus >transmitted by this email. >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com