Thanks Steve and Buddy for the input. I had used the PROJECT to create a Rbase Table but have many and this seemed cumbersome. But the idea of a holding table is exactly what I want. I had forgotten a few other critical steps that you have helped me with. Just for grins: The database that I am creating is to record all the dog races at Victory Land so that I can have a better understanding of how each dog ran over the last month. This way, maybe they won't be eating steak and I can get some of my money back.
Phil Nolette www.ncsgrp.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of J. Stephen Wills Sent: Wednesday, September 25, 2002 9:19 AM To: [EMAIL PROTECTED] Subject: Re: DBase File Merge Phil, I have to use DBF files regularly, so I might be able to offer a couple of ideas. The things that Buddy says are all true and I basically execute those steps. However, I've found that nothing is as simple as it sounds. When working w/our DBF files, I (typically) use a "holding" table approach. Such a table is more-or-less temporary. It is for me to assess the structure and the data. Then I can resolve any variance between the RBase "target" table and the DBase "source" table. Additionally, when the tables are large, I prefer to put the data into RBase (ATTACH ; PROJECT[COPY]), assess it, CREATE INDEXes as necessary, perform corrections via UPDATE, then do the INSERT INTO [RBase_Table] ... SELECT ... FROM [Hold_Table_For_DBF]. This approach has saved me time by enabling me to trap errors before I put the data into a "production" table. Moreover, there is often scant documentation, if any at all, and as what often appear to be like-structure DBF's actually turn out to be unlike, whether in a seemingly minor way, such as a variation on the spelling of a field, or in a major way, such as similar-appearing file names having totally different structures and/or data. As such, I think this extra step is necessary one, as it can prevent many more un-necessary steps later. Just my $0.02. Later, Steve in Memphis ----- Original Message ----- From: "Phil Nolette (NCS Group, Inc.)" <[EMAIL PROTECTED]> To: "Rbase-L" <[EMAIL PROTECTED]> Sent: Tuesday, September 24, 2002 11:46 PM Subject: DBase File Merge > What is the best method to merge over 30 dbf attached files into one Rbase > table and then loose the identity or relationship to the dbase files. > Bottom line is: one regular table with the data from 30 dbf files with the > ability to never reference them again. > > Your assistance is appreciated. > > Phil Nolette > www.ncsgrp.com > > > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: UNSUBSCRIBE rbase-l > ================================================ > TO SEARCH ARCHIVES: > http://www.mail-archive.com/rbase-l%40sonetmail.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
