Clayton, I remember exactly the same feeling of frustration the first times I tried the newer versions of Gateway. On the other hand, now, after a few changes, they operate with far less human involvement than they did the old way. And they are incredibly fast compared to the old imports.
What I did in the meantime -- through a fair amount of trial and error -- was to change the structure of the initial import table to be one that would never encounter any errors. Basically, everything that could cause a problem became a text field in the import table. Vendors who sent dates of 00/00/1973, or some yyyymmdd's and some mm-dd-yy's in the same row, didn't cause headaches any more. I just had to write an "insert into .... select (expression)" to move cleaned-up-data to the real destination table. The import routine runs every day, or even many times a day, without fail, and without a need to check for the exceptions file. Then, I learned about the RGW (R:BASE Gateway) specification files, and was able to fine tune the automation quite a bit more. These RGW-assisted loads are way less problematic than the keystroke "playback" files we used to use to automatic specifications of fields. The stage to look forward to is when you will no longer have to "adjust the data" from the exceptions file and reload it. It really will be an improvement. It just doesn't seem like it today. Bill On 1/15/08, Clayton ANDERSON <[EMAIL PROTECTED]> wrote: > > The exception file contained everything that failed and let everything > that passed go through. The current system stops dead in its tracks, > sometimes keeping what was loaded before the error and sometimes not > depending on how far it got through the file. The major point is that all > validation occurred and failures were given to me in the exception > file. Then I only adjusted the data in the file and then reloaded it with > constraints still intact. It was much easier that what I just went through. > > >>> "Bill Downall" <[EMAIL PROTECTED]> 1/15/2008 8:30 AM >>> > Clayton, > > What did you do with the exception file in old R:BASE? You still had to do > something with those rows that failed to load. > > To my mind, using Jeff's approach with the newer gateway gives you the > best > of both worlds: You can a) get all the data you need into the database, > and > b) determine programmatically exactly what would fail and exactly why it > would fail. > > Old way, you still had to account for and deal with your exception file in > some way. New way you can actually correct some of those things on the way > in, report to your vendor the errors they are making, and log what you > need > to. > > I think in both scenarios you have to use a combination of PC brain and > human brain :) > > Bill > > On 1/15/08, Clayton ANDERSON <[EMAIL PROTECTED]> wrote: > > > > So turn off the PC brain and trust the human to get it right?? Not much > > of a solution. Does this need to be sent to the request for enhancement > > group?? > > > > >>> "Jeffrey M. Watson" <[EMAIL PROTECTED]> 1/15/2008 7:25 > AM > > >>> > > I have noticed the same behaviour, but what you can do is load your data > > to a temporary table with no rules and keys. once it is loaded you can > > 'clean' the data as needed, and append / select+insert it into the > > desired table. Hope this helps. > > > > -Jeff > > > > Jeff Watson [EMAIL PROTECTED] > > Tube Methods, Inc. > > 610-279-7700 > > > > -----Original Message----- > > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Clayton > > ANDERSON > > Sent: Tuesday, January 15, 2008 9:20 AM > > To: RBASE-L Mailing List > > Subject: [RBASE-L] - Importing data using Gateway > > > > The old RBase (DOS 4.5) handled exceptions during data importing with > > the Gateway and placed the exceptions into a except.dat file. Version > > 7.6 seems to just stop when coming across and rule violation. Any way > > to have it continue and/or handle exceptions?? > > > > > > > > >
