>Edmond-
>
>>The data comes in as all text. Even “numeric” data is in text format. Getting rid of any padding doesn’t seem to help much because I had created an ASCII Delimited Text file from my 2 Gig dbf and the text file was almost 2 Gig itself.
>
>I don't understand. YOu say the data comes in that format...but aren't you processing it? I mean, isn't the data we're talking about your clients' data once it's been massaged? If that's the case then why are you restricted to type of data?
>
>>That Help file idea bears thinking about. Interesting idea. The data comes from the post office. It is a list of every street, building, apartment, etc in the country and the range of deliverable addresses. It also has information in order to match street nicknames, add the zip+4, add the carrier route, etc. The idea is to take an address from the client’s mailing list, massage it to get it into standard format and try and fix any errors, and then match it with the national database in order to supply the zip+4 extension, carrier route, and other necessary information. There will have to be a number of queries against the data by state, or city, or street name, etc. so I’m not sure how the Help idea would work in this case. The queries would all be figured out on the fly depending on what information is in the original address, how bad a form it is in, and if any matches can be made early on.
>
>Even more confused. _What_ data is on the CD? The client's data post-massaging? Or the P.O. data? Or both? Do you send each month the new P.O. data to your client? Who then runs your application against the P.O. data?
>
>>A DVD would be out of the question. I would have to stay competitive with the other vendors and they are all distributing the data on CD. Delivering 10 CD’s every other month (that’s how often the post office publishes new files) would also be out of the question.
>
>Do your clients run the application and data from the CD, or could they install it from CD to a local harddrive? In which case why not just use an installation routine?
>
>>Do you know of any other database who’s data is this compressed? Paradox (DB) or whatever?

These three vendors
>
>If I was looking to market a product with existing stiff competition, I'd first own copies of probably 2 of the best competition, and I'd find out what the data really is that's on the CD.
>
>We don't really at this point have any idea of what those other guys are doing.

Nancy,

I have the applications from three vendors that have both their applications and the PO data on one CD. The norm is to install the app to the hard drive but to leave the data on the CD.

Everybody gets the same raw data from the Post Office which is something like 450 Meg of zipped fixed length text files. These text files will create 6 Gig of dbf data. What I don't know is in what form the other vendors are storing the data. In running their various apps I can tell that they have all of the data available but stored in about 450 MB of file space.

I have their data but I have no way of finding out what form it is in. It won't open as a xBase table although they could have used a LLF function to change one byte which would keep it from opening but I doubt that it is a dbf because how can you take 6 Gig of data and reduce it to 450 MB.

My question is how can I find out what format this data is in? Once I know that then I can figure out how to work with it. Opening the data files in text mode or as a Hex dump doesn't reveal anything that I can tell about the data format's origin.

I was hoping that someone might know right off of the bat that a particular type of database happens to have an incrediblly small footprint or some way of checking the source of a data file.

Any ideas are appreciated. This file size thing is very important to continuing with the development of this app.

Ed