I'm trying to solve this problem myself. Need to have the file onto an SD Card to use for an onboard propietary (old) truck computer. The only work around, which works fine, but isnt the best, is on the last script step I select the entire field, then copy. Then I open a notepad text file and paste. Export Records, and Export Field Contents, don't seem to bring the LF and CR with them.
Single field export might be part of the problem.
Here's an article about a possible solution:
This type of "export" preserves whatever characters you put into the field, including CRLF if needed. XML does not convert these. Something similar can be used with many field(s) and/or record(s), using an appropriate XSLT.
This is one of my XSLT for creating ".csv". It quotes all the field values and adds the appropriate end-of-line (you need $#13;$#10; ):
<?xml version="1.0" encoding="utf-8"?>
<xsl:output method="text" version="1.0" encoding="utf-8" indent="no" />
<!-- end-of-line = carriage return, change as needed -->
<xsl:variable name="eol"><xsl:text> </xsl:text></xsl:variable>
<!-- Header line, inserted only once; if not desired, remove -->
<xsl:text>Name,One,Two,Date_Created,TS_Created</xsl:text><xsl:value-of select="$eol" />
<!-- LOOP THROUGH THE RECORDS (as ROW) -->
<!-- LOOP THROUGH THE FIELDS (as COL/DATA) -->
simplified with &x22; (also know as double-quote character)
instead of text, value, text, just CONCATENATE
<xsl:value-of select="concat('"', ., '"')" />
<!-- ADD A COMMA AFTER A FIELD IF IT IS NOT THE LAST -->
<xsl:if test="position() != last()"><xsl:text>,</xsl:text></xsl:if>
<!-- BY DEFAULT THE END OF THE RECORD/ROW GETS A RETURN -->
Note also that the first column (header) is the fields named as you want (the same order as your export). If you have related field export, then that's something different.
Plug-ins may also assist you with the type of export you need.
The problem is that Filemaker using a single CR to terminate text lines. In Notepad it appears a a square box character in that long line. Unfortunately the developers at Filemaker seem to live in an Apple way of doing things only world. The rest of the world uses CRLF as is the proper way to terminate a line for greatest compatibility. CR means carriage return, or move to the beggining of the current line. LF is Line feed and means move cursor down one line. In a proper text terminal a LF by itself wil mocve down one line without oving to the beggining of the line. SImilar with CR will move to the beggining of the line without moving down a line.
From a programming perspective, using a single token character to indicate the end of a line is more efficient and manageable. Filemaker uses a CR, Unix use LF, most programs interpret a CRLF pair as a single operation and internally replaces the pair with a single character such as CR or LF. The trick is to do a conversion back to CRLF when writing the file.
A way to do this is to search and replace the CR (That Pi 'ish looking symbol) character with
& Char(13) & Char(10) &
Note the catenate operaters. A special case to consider is the end of the text. You do not want that last catenate. Often it is best to have a final CRLF as the last characters in a file.
One other note. since you are operating within a text string, you will probably have to unquote then quote to use the replacement. use the slash quote to use it in the replacement string.
If you see my article, I explain this. That is why I use XML export with XSLT to give me the characters in fields (even calculated). In addition, characters can be added by the XSLT as needed.
-- sent from my iPhone4 --
This worked (as soon as I realized that your XSLT file only added the CR ( ) and not both a CRLF ( ). Thank you for your response. It has encouraged me to learn a little bit more about XLST (something that I knew little of before)
These are simple examples and unless you have really complex XML schema to output, may be all you need to learn!
-- sent from my iPhone4 --
One last bit of housekeeping...
The exported file using this technique does not have a file extension (despite my export path specifying one explictly by concatonating the path and document name with ".csv").
While not a deal breaker, it really would be nice to know why...
one last bit of housekeeping:
you're not exporting correctly to make the extension as you need it!
How are you naming your export? Manually? scripted? are you setting a variable first and using the variable in the dialog? You need to NAME the file, fully even if you use XML export method.
I do this all the time with XML. Just make it the extension you need....
I am setting the output path for the Export Records script step with a variable ($path)
This variable is a concatonated string of Get (DocumentPath) & fileNameFromAField & ".csv"
The variable resolves properly in Data Viewer (when debugging) to:
But when the file is created upon export, it is just called "examplefilename"
At first I thought that I had forgotton to unhide extensions in the Finder Preferences, but that was not the case. Using Terminal.app, the file clearly does not have an extension at all.
the "path" needs the prefix:
I wonder if that's making the document extension less?
Also, any other apps running or plug-ins?
What are the permissions on the Documents folder/directory? Might you need to run an OS utility to fix permissions or something?
I figured out why I was not getting the extension. The file name comes from a passed parameter into the script, and Get (ScriptParameter) was receiving a LF so my path was resolving to:
The extra line feed is coming from a field that was populated via a SQL Server import (and was entirely unexpected). Sometimes I forget just how much I love computers!
I hate when that happens! I tend to put in a "substitute(... ; "¶" ; "") when setting the path. I also try to remove things that may break (":" , "/" , basically any standard path delimiters). I don't like spaces either.
If ever there was a job for a custom function (either to simply remove illegal characters or, if you are playing on the interweb, swop them for the relevant encoding)
Were you getting invisible files (.csv) being created too? I’m wondering if the command is happy to work with a list.