Exporting TAB or CSV windows friendly

[donwolfkonecny]

I need to export data to another database.

 

When I export TAB or CSV, as Macintosh, Windows ANSI, or DOS ASCII, there is apparently a funky character or something included. When I go to import into 2 other databases (both are web based imports) they don't recognize the EOF and interpret the entire file as one line.smiley-frown

 

I have been temporizing by reading the file into excel, then saving it as CSV windows, but now I need to automate things. I tried setting up AppleScript which I've never used before and it doesn't appear to work inside excel.

 

I speak pidgeon unix (as needed) but I'm not fluent.

 

Anyone know how to do this within Filemaker or without?

 

After this, I need to append column headers so if anyone's got ideas on that, let me know. (I need to append a line of text to a text file.)

[sbg2]

Are you using Export Field Contents or a normal export.

 

See the folloiwing if you are using Export Field Contents as I suspect:

 

http://fmforums.com/forum/showpost.php?post/276047/

[donwolfkonecny]

No I am using "Export Records..."

 

Are you using Export Field Contents or a normal export.

 

See the folloiwing if you are using Export Field Contents as I suspect:

 

[sbg2]

Does one of your fields contain a Carriage Return within Filemaker? If so this is a reserved character used in the .tab and .csv file format to denote a new record. Therefore some other character must be substituted to replace the carriage return within the Filemaker field.

[AHunter3]

Untrue in practice, because a hard return in a FileMaker field is actually an oddball character known as a vertical Tab. (FileMaker would not be able to accomodate a true hard return in a field either, as it, too, uses a true hard return as a record-delimiter).

 

This may be the "funky character" but it should not cause other systems to fail to see the true hard return between records, nor should those other systems confuse the vertical tab with a true hard return. (If that latter WERE occurring then rather than everything being blobbed together on one line you'd have lots of artificially short "records" with records being broken at every point that a carriage return was encountered in a field).

 

It may be the difference between native Mac end-of-line (carriage return), unix (linefeed), and windows (combo of the two, if I recall correctly).