| |
|
If this is your first visit, be sure to check out the FAQ by clicking the link above.
You may have to register before you can post: click the register link above to proceed.
To start viewing messages, select the forum that you want to visit from the selection below.
|
 |
|

01-27-09, 15:13
|
|
Registered User
|
|
Join Date: Jan 2009
Posts: 9
|
|
|
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
|
|

01-30-09, 19:07
|
|
Registered User
|
|
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
|
|

01-31-09, 12:09
|
|
Registered User
|
|
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
|
|

01-31-09, 14:29
|
|
Registered User
|
|
Join Date: Jan 2009
Posts: 9
|
|
Why does my thread keep shwing up as "Moved" ? This is the forum I originally posted to???
|
|

02-03-09, 08:32
|
|
Registered User
|
|
Join Date: Jan 2009
Posts: 9
|
|
The files at issue were created with "Canofile" from Cannon.
Any thoughts??
|
|

02-06-09, 14:51
|
|
Registered User
|
|
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
|
|

02-06-09, 15:46
|
|
Registered User
|
|
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
|
|

02-06-09, 15:59
|
|
Registered User
|
|
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
|
|

02-06-09, 19:32
|
|
Registered User
|
|
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
|
|

02-07-09, 08:26
|
|
Registered User
|
|
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
|
|

02-07-09, 12:21
|
|
Registered User
|
|
Join Date: Jan 2009
Posts: 9
|
|
There is just one TIFF file per record.
Any suggestions as to how I can read that data?
|
|

02-07-09, 14:42
|
|
Registered User
|
|
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...
__________________
Tibor Antal
Budapest
Hungary
|
Last edited by INComplete; 02-07-09 at 14:46.
|

02-07-09, 15:16
|
|
Registered User
|
|
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??
|
|

02-07-09, 17:53
|
|
Registered User
|
|
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
|
|

02-08-09, 15:37
|
|
Registered User
|
|
Join Date: Jan 2009
Posts: 9
|
|
I'll run a report and document the associated files tomorow.
|
|
| Thread Tools |
Search this Thread |
|
|
|
| Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
|