Page 1 of 2 12 LastLast
Results 1 to 15 of 17
  1. #1
    Join Date
    Jan 2009
    Posts
    9

    Unanswered: Trouble with fields in DBF file

    I have a DBF file I am trying to convert to CSV for migration to a new application. I can open the file with Access & Excel but a few of the fields are not readable. I am seein the following in certain fields:

    
    @@@@@@@@
    &9%

    Other fields are readable. Any suggestions as to tools or techniques for successfully reading these files?
    I have attached a sample.

    Thanks

    Steve
    Attached Files Attached Files

  2. #2
    Join Date
    Jan 2009
    Location
    Florence, SC
    Posts
    10

    Could it be a date field?

    OR blow away the dbase index. Maybe its trying to read the index associated with the dbase file.

    What I would do is this: Convert your dbase file into a csv. Write a conversion program to create the csv file from the dbase file, Then you have a good csv file that you can import to excel. Then you are set. Then you can go anywhere with the data.

    If you need a conversion program written shoot me a copy of the dbase and I'll write one for you.

    Hope this helps...
    Pappy

  3. #3
    Join Date
    Jan 2009
    Posts
    9
    Pappy,

    Thanks for the reply. It would be great if you could give me a hand with a conversion program. I can send you the dbase. It is 30mb zip file. How shall I send it to you? email? FTP? Yousendit??
    Thanks again.

    Steve

  4. #4
    Join Date
    Jan 2009
    Posts
    9
    Why does my thread keep shwing up as "Moved" ? This is the forum I originally posted to???

  5. #5
    Join Date
    Jan 2009
    Posts
    9
    The files at issue were created with "Canofile" from Cannon.

    Any thoughts??

  6. #6
    Join Date
    Aug 2002
    Posts
    233
    Quote Originally Posted by mohave_steve
    
    @@@@@@@@
    &9%
    It's correct, because Excel can not show these kind of characters (ASCII<<32), BUT, do not worry, there will be no problem to convert them.

    If the file doesn't contain more than 65.535 lines (which is the maximum value, Excel can handle.), than You can do it in one stem, if not, then cut the original file into for example 50.000 records segments (easy to check the records), then:

    Simply OPEN it,
    do not mind the looking,
    Save it as CSV.

    DONE.

    Check it with ->dos->edit (the dos edit program), and there will be ALL original information with the CSV format.

    I think, that's all, if there was NO ";", or some strange info in the data area, because it can harm the conversion.

    Please inform me, if my solution worked, on my side, I've checked Your sample, and it seemd working fine
    Tibor Antal
    Budapest
    Hungary

  7. #7
    Join Date
    Jan 2009
    Posts
    9
    Thank you for your reply.
    I tried what you suggested:
    1) Opened DBF in Excel.
    2) Save As CSV.
    3) Opened with DOS Edit.

    The fields are still showing unreadable information. See the screenshot I have attached.
    Was my procedure correct?
    Any assistance is greatly appreciated.

    Steve
    Attached Thumbnails Attached Thumbnails dos_edit_screen.bmp  

  8. #8
    Join Date
    Aug 2002
    Posts
    233
    Dear Steve,

    These are the information in the database file, byte to byte, You see on the attached screen! Please check, it's NOT the same, You've seen in the excel, because there were not any useful information in the first five columns, here You can see them.

    It seems to me some kind of a "coded" text, or a checksum, but maybe some kind of an "index" value, but NOT any useful information.

    It seems to me, that "Index_no" is a field for the "index code" in HEX format, "page count" is also some additional info in HEX format, the "index_cell" is filled with "@" and only with "@". Entry date and Rev date used to be a database info on when it was entered and revisioned, tha "marks" field is always empty.

    So it seems to me, these fields does not contain any info You need to convert the database.

    Are You sure, You miss some information? If Yes, maybe that information are NOT exists in these table, but in another table "linked by" these values.

    What information do You miss from this dbf file?
    Tibor Antal
    Budapest
    Hungary

  9. #9
    Join Date
    Jan 2009
    Posts
    9
    Tibor,

    There is an index that links each record to an associated TIFF image file.

    I need to be able to associate the information contained in each record with the image file that it belongs to.

    Thanks

    Steve

  10. #10
    Join Date
    Aug 2002
    Posts
    233
    Quote Originally Posted by mohave_steve
    There is an index that links each record to an associated TIFF image file.
    Yes, it's possible, but in this case, THESE are the index fields, so there are at least two options:

    The image file names are encoded - in this case we need to know the decode algorithm (Fe: The file name contains only numbers, and these fields stores the names as HEX codes)

    There is ANOTHER file, which handles the real file names, and the indexes in these fields.

    Is there any other database, which is "not readable" just like this?

    There is only just one little thing, that is dead sure: These fields are READABLE, but surely not contain the real file name!

    (Just a remark, if there used to be MORE pictures for one record, then there MUST BE another database, which contain the file names for a record!)
    Tibor Antal
    Budapest
    Hungary

  11. #11
    Join Date
    Jan 2009
    Posts
    9
    There is just one TIFF file per record.

    Any suggestions as to how I can read that data?

  12. #12
    Join Date
    Aug 2002
    Posts
    233
    Quote Originally Posted by mohave_steve
    Any suggestions as to how I can read that data?
    There is absolutely no problem to read the data - they are there, You can see them for example on Your screenshot.

    The problem lies elsewere.

    The problem is, that we do not know what are these information mean!

    You know, that there should be a rule, which connects any record to a specified tiff file, but You have to understand, that it's an algorithm, or a rule, but NOT a real file system's file name! So, You will NOT find the tiff file name there, because NOT the REAL file names are stored in the database, but the value of the rule from which the algorithm can regenerate the "dos" file name.

    This means, first of all we have to figure out this algorithm, because without it, there is almost no chance to connect a file name to this standalone database...
    Last edited by INComplete; 02-07-09 at 15:46.
    Tibor Antal
    Budapest
    Hungary

  13. #13
    Join Date
    Jan 2009
    Posts
    9
    I can manually match a sampling of records with files if that would allow us to recreate the algorythm.

    See the input, see the resulting output and figure out what lies between??

  14. #14
    Join Date
    Aug 2002
    Posts
    233
    Quote Originally Posted by mohave_steve
    I can manually match a sampling of records with files if that would allow us to recreate the algorythm.

    See the input, see the resulting output and figure out what lies between??
    It's worth a try
    Tibor Antal
    Budapest
    Hungary

  15. #15
    Join Date
    Jan 2009
    Posts
    9
    I'll run a report and document the associated files tomorow.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •