From: dishborealis@yahoo.com   
      
   Not exactly sure what you mean, but all 3 text file columns are being   
   imported into a table formatted only with alpha fields, since no math is   
   done on the numbers. Here are a few lines of the text. In the actual file,   
   that 3rd column is actually right-justified, nice & neat, but will probably   
   appeared skewed in this message.   
      
   01600010610           GOLD MEDAL ALL PURPOSE FLOUR   
   1161001   
   01600010640           GOLD MEDAL HARVEST KING BREAD FLO               375001   
   01600010710           GOLD MEDAL ALL PURPOSE FLOUR   
   460541001   
      
      
      
      
      
   "Régis"  wrote in message   
   news:45ad46da$1@pnews.thedbcommunity.com...   
   > Just a thought;   
   > Can it be linked to a smallint limit?   
   > Régis   
   >   
   > "JoeSpareBedroom"  a écrit dans le message de   
   > news: 82brh.725$ya1.389@news02.roc.ny...   
   >> This was a fixed length file, so delimiters weren't the problem, although   
   >> I know what you mean. The files I get often have commas in the product   
   >> descriptions. Since they serve no useful purpose, in terms of legibility,   
   >> I do a search/replace and turn them into spaces.   
   >>   
   >> As far the source of the file, you're probably correct about the "wrong   
   >> turn". I have no control over what the vendors send us, unfortunately. A   
   >> few of the companies have had consistent procedures in place for 10   
   >> years, as evidenced by the age of my flimport spec files. Others think   
   >> it's fun to change their formats every 3 months.   
   >>   
   >>   
   >>   
   >> "Michael Kennedy"  wrote in message   
   >> news:cWarh.17508$j7.339594@news.indigo.ie...   
   >>> As Ed has covered, it's most likely that each line is not ending with   
   >>> the CR/LF pair (Hex 0D/0A). You should run a HEX viewer to check the   
   >>> original file - any other "editor" may lie to you - some will   
   >>> automatically repair a lone CR, or a lone LF, or a reversed LF/CR, to a   
   >>> "proper" CR/LF pair, and then you'll not be any wiser at the end.   
   >>>   
   >>> If it's a CR/LF issue, then you'll need to trace back to the source of   
   >>> this file - I expect someone there took a wrong option... or prepared   
   >>> the file for a UNIX platform... or...   
   >>>   
   >>> Ed has also covered the EOF issue...   
   >>>   
   >>> Finally, all the PDox "Import" routines - that I'm familiar with - are   
   >>> not very smart on CSV files, where the field separator char (usually ,)   
   >>> and/or the field delimiter char (usually ") are embedded within string   
   >>> fields.   
   >>>   
   >>>  - Mike   
   >>>   
   >>> "Ed Nash"  wrote in message   
   >>> news:45ad19a3@pnews.thedbcommunity.com...   
   >>>> JoeSpareBedroom wrote:   
   >>>>> Not that I can see in WinEdit. However:   
   >>>>>   
   >>>>> - If I open the text file in Word using the "Show All" option, there's   
   >>>>> a paragraph mark at the end of each line.   
   >>>>>   
   >>>>> - If I copy the text from the offending file into a new file, the   
   >>>>> import works. It's a minor extra step, but still, I'm curious.   
   >>>>   
   >>>> One other thought... some programs that create text files put an   
   >>>> end-of-file marker (non-visible) after the last CR/LF.  My experience   
   >>>> is that Paradox doesn't like it.  I suspect that when you copy/paste   
   >>>> you are not bringing along that EOF byte.  Try deleting it with a hex   
   >>>> editor or even using the backspace key after opening the file in   
   >>>> Notepad.  Then re-save and re-import.   
   >>>   
   >>>   
   >>   
   >>   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)