I'm stumped with you as to what to do at this point. I guess if you have spaces in between fields, just read the entire record into one text field and then have a program operation which reads to the first " ", grabs the text, moves it to the first field, then go to the second " " and do the same thing. Use the AT function filling the substr(gcfield,[start],[#char]) with variables.

Bill


>I replaced the tabs with commas using the backspace key, since it was a small test file. It didn't help. Since the wizard indicated it was looking for tabs or commas, I assumed that I wouldn't have to tell it that the delimiters were commas.
>>Then it would appear that VFP import wizard is not recognizing the tab as a tab. Try and insert "," where tab goes and see if that works (provided that your text program recognizes the tabs for a global search and replace) and see if you can insert that separator in the text delimited designation.
>>
>>>The field sizes in my example are not the same. They are tab delimited.
>>>>Try using the SDF designation. If field sizes are the same, you need to determine the starting positions of each field and conform your table to that format(with fillers for obvious blank spaces). After you read your table in, you can re-export it to a new table with revised field lengths and eliminate filler fields if you need to.
>>>>
>>>>HTH,
>>>>
>>>>Bill
>>>>
>>>>>I have a very simple text file I wanted to import. It was tab delimited, but the import wizard said it wasn't. So I tried replacing the tabs with commas. The import wizard said it wasn't tab or comma delimited. I even tried enclosing the field values with "", but it didn't help. Finally, I replaced the commas with spaces so that the records were equal length. The wizard was able to tell where the fields should go. I was able to do all this because it was a very small file, but in general it seems like the import wizard is useless. What's going on?