Aw! It would have been nice to see you in Ft. Laud Don! Chris
Date: Sun, 6 Mar 2011 11:47:17 -0500 From: [email protected] To: [email protected] Subject: Re: [Dataperf] Problem with incrementing number Brian - naughty indeed! I'm writing from an enclosed porch overlooking a golf course in Orlando. We own a handful of timeshare weeks with Marriott and were on the beach in Ft. Lauderdale last week, this week in Orlando. We're both sitting back here spending the day on our computers but unlike Ft. Lauderdale, the weather here is a bit cooler today. Actually left Ft. Lauderdale early yesterday, drove just about five hours to Clearwater in order to catch a Pittsburgh/Philadelphia spring league (pre-season) baseball game, then down to Tampa for dinner and over to Orlando to check in. I have to fly home Wednesday evening for election work responsibilities, Rhoda will drive home Saturday/Sunday. We did southern France and Switzerland last fall, Aruba for a week in early February and now this. My schedule is really tied up between now and May 17th, I have about a dozen candidates in four counties for whom I performing a myriad of political services centering around message and delivery. I'd catch you along the trail if I could work it in, would have flown down here around Christmas to say Hi if I had known. The West Coast is more difficult of a flight. I'll package up a zip file later and let you take a look at it. Obviously I have a solution so it's not imperative but I thought it was an interesting problem. Don 2011/3/6 Brian Hancock <[email protected]> Hi Don, I was very naughty and did not let anyone know… I was in Florida for a week over Christmas. In May I will be doing some travelling in California, starting out in SF, going thru Yosemite, to Mammoth Lakes, and then over to LV, the Grand Canyon, Zion, and Bryce Canyons and then to LA before heading back to Sydney, a whirlwind trip. If you would like to Zip up the files including existing data (I presume you have tried importing to an empty panel) plus the import file I can take a look. As I said I do not think it likely to be a processor speed issue, have you tried it on something slow, or on any different machine. I could be wrong on this and a try on a slower machine with the same data might be a simple example… Regards Brian From: [email protected] [mailto:[email protected]] On Behalf Of Don Friedman Sent: Sunday, 6 March 2011 3:03 PM To: [email protected] Subject: Re: [Dataperf] Problem with incrementing number 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 -- 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
_______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf
