> the MVR table is crap. Ford is Frd, Ford, For, etc. > Don't you just HATE having to set up a relationship between mulitple tables when one, more or all tables have crap data on the very fields you need to analyze? I have many a time had to create a set of correlation tables, and regression analysis code for substring matches with varying degrees of confidence. Addresses are always a bitch, so I wrote code that pulls out the street number and core street name (or full PO Box/POB/POBx/etc.) from these multiple tables to help with the task. And gee, let's not forget the names (Richard, Rick, Dick could all be the first name of the same person in multiple tables).
I just went through a regression analysis trying to match up a set of 3,300+ Chevrolet records (from GM) to the records for a client using my DCMS application. GM only provided the last name, first name, business name if a business, street address, CSZ, home phone and work phone. They have the VIN available, but did not provide it. I spent days (while working on other concurrent projects) doing a record match based on various data elements looking for matches. In the end I got all but 167 matched, and manually tried to look up the custoemrs within DCMS. No luck. Turns out when a Chevy owner moves GM reassigns that customer to the nearest dealer! So, after I do all that I help the dealer out by putting together some documents for the promotion he has in mind (he was supposed to do all the artsy-craftsy layout stuff, but with the GM deadline looming he was not moving on it fast enough). I called yesterday to advise we had to get the marketing documents wrapped up so I could MailMerge the letters with the narly 3,200 records to make our target deadline. His response? "Oh, you know what, I have been so busy that I never was able to get the marketing letter done. Let's just scrub the project." F*&k Me Blind! Say what?!? I spend hours on this project to make certain my correlation matches are solid, and even try to spoon feed the client, and he scrubs it because he was too busy to go over the stuff I sent for him to polish! That client is on very thin ice. I sure did not need the practice on that little project. Grrr... Gil > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of John Harvey > Sent: Friday, April 25, 2008 3:40 PM > To: [EMAIL PROTECTED] > Subject: RE: VIN Decoder > > > Yeah, I found a bunch of links too. Problem is, our local county > clerk isn't > doing the job and the MVR table is crap. Ford is Frd, Ford, For, etc. > > I've got 1.5 million records to unscrew. > > JH > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Gil Hale > Sent: Friday, April 25, 2008 1:14 PM > To: [email protected] > Subject: RE: VIN Decoder > > Duck & Cover! I have never needed to use a VIN Decoder, as my use of VINs > is more for relational link (you know, Joiner Fields <g>), and referential > lookups. The in-house systems I pull raw data from already have the Year, > Make and Model info I need. I do know I did a Google search for > VIN Decode > a few years back, and got lots of hits... > > Gil > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Ed Leafe > > Sent: Friday, April 25, 2008 1:02 PM > > To: [EMAIL PROTECTED] > > Subject: Re: VIN Decoder > > > > > > On Apr 25, 2008, at 11:45 AM, John Harvey wrote: > > > > > Anyone got a class for decoding a vin number. I found a snippet that > > > will at > > > least do the checksum and return the year. I've also got the > > > guideline for > > > how to decrypt the number, but I figured if someone else already had > > > it... > > > If nobody does, but wants the code I found, and the guideline, I'd > > > be more > > > than willing to send it. > > > > > > Gil? Where are you when we need you, Gil? > > > > -- Ed Leafe > > > > > > > > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
