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
