Not all will easily go into Text format.
For example: If the data table should have a Memo field, that will be challenging to put into your Text format.
Why do you want without using COPY TO ... TYPE DELIMITED ?
That is the easiest way to put data into a Text format. You can DELIMIT in a variety of means (see VFP Help for COPY).
If you are looking for a more formatted (pretty) text format when printed onto paper, then you will need to consider a routine which will handle each type of table separately.
If you can provide more information as to what you are trying to do, we might be able to help you better.
Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
No memo field in my table. Following are the reason to avoid
1) The file was all one big long line with no indication on when a particular record ended
2) if any name or address contain a comma character, it treated it like the end of that field/column and that meant that the values all went into the wrong columns. So we cannot depend other delimited also
The file was all one big long line with no indication on when a particular record ended
There has to be something which can be used to determine when a record has ended. Otherwise you have one BIG record and I am sure that is not what is intended.
Have you used a HEX editor to look into the 'internals' of the file to see if you can determine any special characters which might be used to terminate individual records (e.g CR or LF, etc.)?
If there is absolutely no end of record indicator, then how will you know when to start a new record?
If you can visually determine the start of a new record by either character count or some unique character string or something else, then you can use that within your code.
2) if any name or address contain a comma character, it treated it like the end of that field/column and that meant that the values all went into the wrong columns. So we cannot depend other delimited also
Yes, commas within a field itself can cause problems, but you must have some way to differentiate between commas within a field and other commas.
You say that there are no end-of-record indicators, but you haven't said if there are field separators (e.g. Commas, TABs, etc.). Those may also be of help when extracting data.
Even if you write a low level FP program to parse the text and extract it into separate fields (which I have done numerous times), you still need to determine some 'rules' to use based on unique character strings, unique individual characters, or other such means to indicate when a field has ended and when a record has ended.
It sounds like you need to do some more 'homework' into what you do have and then we can help you utilize that to get the data out.
Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.