Hi there,
We developed a program that takes data right out of FileMaker and
going directly into a shell script for some processing.
On the export records steps, in the "Output file character set"
option, I choose Macintosh so that the file is unix and not dos or
anything else. In the resulting shell, all steps (actual FileMaker
records) are separated by the Dos ^M carriage return characters and
therefore the script doesn't run. I know that those characters are
there because I see them using any character editor on Mac. I used
unix vi editor and replace the characters with unix carriage return
and the script ran successfully. Is there a way to change the Dos
carriage return delimiter via function or some other way that I'm not
aware of? It's my understanding that FileMaker will export text
(comma/tab separated) while delimiting the records with a carriage
return. Also changing delimiter depending on your output file
character set option? Is this a bug? I bet everything will be fine if
the server was windows.
What I have tried with no luck
1-Forced inserted the character after each record (they came out as
vertical tabs)
2-Trim any weird characters between records using a custom function
(didn't work because FileMaker using it's own fancy delimiters for the
records after reading the record)
3-The obvious, selected Macintosh on export record options.
4-Created a Global field and looping the found set in it then
exporting the global field. (same reason as #2, records are being
delimited by FileMaker)
Any advice? Anyone ever needed to style while exporting records? Try
and export a few records in txt and let me know if I'm missing
something.
Thanks in advance
-
zloua...@gmail.com
On Feb 8, 2:41 pm, Charlie Bailey <char...@inresonance.com> wrote:
> Z,
>
> I've done some testing here and get the same delimiter no matter what format
> I choose (CSV/ANSI, CSV/DOS, CSV/MAC, MER/ANSI, MER/DOS, or MER/MAC). If
> you're writing shell scripts anyway - why not just parse this export file
> and replace the offending delimiter with a more appropriate one?
>
> - Charlie
>
> --
> Charlie Bailey
> EVP Product Development and CTO
> inRESONANCE
> Northampton MAhttp://twitter.com/charliebailey
>
> On Mon, Feb 8, 2010 at 2:08 PM, zlouatt...@gmail.com
> <zlouatt...@gmail.com>wrote:
> > zlouatt...@gmail.com
>
>
On Feb 8, 2:51 pm, Charlie Bailey <char...@inresonance.com> wrote:
> Of course - XML! Absolutely - that will be the most flexible solution. I
> should have mentioned that in the first place.
>
> - CB
>
> On Mon, Feb 8, 2010 at 2:46 PM, zlouatt...@gmail.com
> <zlouatt...@gmail.com>wrote: