Brian - Hi and thanks for the input. When are you coming stateside again? Be sure to let Rhoda and I know, don't know when we'll be back in Australia again.
As regards this issue, I agree with you except that in this case it's really a simple import with no complications. What I have is a .csv file that I first bring into a spread sheet in order to do a bit of sorting to eliminate record types I don't want. I then save it as a .csv file again and import a total of eleven field into a small, single panel database. I need to use a control file number as an index so I used an ::I field. The result was that the import kept failing, failing at different points in the import. After working through all the various scenarios without fixing the situation, I simply added another field to the spread sheet, an incrementing number, and used that as an index. Then the import worked perfectly. I then tried the ::J suggestion. Again, failure. Used the spreadsheet-generated incremented number, no problems. I certainly don't know what the problem is but I'm having a tough time figuring out what it could be if it's at my end. Don 2011/3/5 Brian Hancock <[email protected]> > Hi guys, > > > > Personally, although I could be wrong, I do not think this is a speed of > processing issue. This is not a Windows application making an asynchronous > call to COM object and hoping it has finished its job before you do the next > step, but rather this is a nice monolithic program working step by > synchronous step, so I would be surprised if parts of the program are really > getting ahead of others in a way that the STR file is not updated in time > for the next record to be imported. But I could be wrong… > > > > Although I now do not like ::I fields for the fact that it makes the STR > portability problematic, I have many older applications using ::I fields, > and I am constantly importing and exporting data, and I have worked on some > pretty fast processors under a variety of operating systems, but I have > never come to the conclusion when I have had similar importing problems that > processing speed was too great. > > > > Actually, what I always find is that something is not quite what I expected > in my program or in the data I was importing. > > > > Some examples, which might give clues to where simple things can really > foul up. > > > Once I had a database that worked for ages, with data importing and > updating all the time. Then I had to establish a link between company and > subsidiaries, so I did that with a recursive datalink on a field. Problem > was during import if the parent record did not exist due to the order of the > import, then the import would fail. Parents must come before children, > unless you remove checking from the link. > > > > Another time, I found that I had a couple of records which inadvertently > had more fields, there was some spurious data a few columns across when it > was exported from Excel. That caused problems. > > > > Another had page breaks in the data, this is an easy thing when you are > exporting data from DP to a CSV, and you forget about the page length in the > report. > > > > Hidden fields on the Excel Spreadsheet have also tripped me up as they come > out in the export to CSV or TAB file. > > > > Embedded commas in data fields can also bugger your day. > > > > I have found no end of blunders I have made that have had me scratching my > head about why an import was not working properly. > > > > Happy hunting > > Brian > > > ------------------------------ > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Don Friedman > *Sent:* Saturday, 5 March 2011 12:29 PM > *To:* [email protected] > *Subject:* Re: [Dataperf] Problem with incrementing number > > > > Rich - I replicated the problem this evening using the ::J incrementing > number. I then tried moving the field to the first in line order rather than > last with the ::J and the problem continued. Again, I added my own > incrementing number to the raw data and imported without a problem. I'm not > running anything special, just a Lenovo laptop running Win 7. I'm really > wondering what the story is on this, maybe it is the speed of processing. > > > > My wife and I have been enjoying the sun in Ft. Lauderdale all week > spending the hottest part of the afternoon and our evenings doing assorted > computer work - she on her web site and blog, me on voter data files that > I'm working with this election cycle. Mornings we take a long walk and late > afternoon lie on the beach with a book. It's just great. Your weather in > Morgantown can't be a lot better than Pittsburgh's. Will catch a Pirates > game at Philadelphia's home field in Clearwater tomorrow, then drive to > Orlando where we have a place for a week. > > > > Come to think of it Rich, you should know that I have great seats for > Pirates games (I share a pair of season tickets with two other fellows) and > if you ever want to catch a game drop me a line and you can be my guest. We > sit right behind home plate, just a few rows behind the visiting scouts. > > > > Don > > > > On Fri, Mar 4, 2011 at 9:11 AM, Rich Bragonje <[email protected]> wrote: > > Hi Don, > > If it wouldn't be too much trouble, could you run your import using > the ::J option to see if that does take care of the problem? I sure > would like to know. You never know when that one bit of knowledge or > experience will be the one you need. > > Thanks, > > Rich > > > At 07:26 AM 3/4/2011, you wrote: > >Pat - thanks - makes sense to me. I forgot all about the ::J options > >and even if I had remembered, wouldn't have thought to use it to > >solve this issue. > > _______________________________________________ > Dataperf mailing list > [email protected] > http://lists.dataperfect.nl/mailman/listinfo/dataperf > > > > > -- > Don Friedman > ProfessionalRecords.Com LLC > PRS Data Systems > 205 S Main Street > Pittsburgh, PA 15215 > 412-784-1600 - 1-800-PRS-FILE > 412-784-1615 Fax > > _______________________________________________ > Dataperf mailing list > [email protected] > http://lists.dataperfect.nl/mailman/listinfo/dataperf > > -- Don Friedman ProfessionalRecords.Com LLC PRS Data Systems 205 S Main Street Pittsburgh, PA 15215 412-784-1600 - 1-800-PRS-FILE 412-784-1615 Fax
_______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf
