XML removing return character in fields

[DABrad]

Hello, after searching the forums for this specific problem, I couldn't find any reference to it. My apologies if I missed a post.

In exporting/importing data from one FMP datafile to another FMP datafile using FMPXMLRESULT, critical return characters are being removed from a field.

Is this fixable through an export setting? Or is the only way to go is XSLT?

Thank you in advance for any comments or suggestions.

[QuinTech]

Can i ask why you're using XML for this? Couldn't you just do an import from the target FM file?

Jerry

[DABrad]

The datafiles sit on separate computers. One is a server in a co-location using a static IP. The "updater" is on a workstation using a dynamic IP. Scripting an import algorithm for the remote would be possible if the workstation had a static IP. But, that's not an option for the workstation. The XML import/export algorithm works great... except for this one issue.

Thank you for your reply.

[QuinTech]

Oh, i see. Well then-- i've had difficulty with CR/LF in XML before and have never exactly worked it out. (In fact, i've even asked some people at FM Inc. who know about XML and they were sort of befuddled too.) So i can't answer your question directly, though someone else here may be able to.

But i used this as a workaround: Before exporting, replace all "" with some unique flag, say, "!@#$#@!" which you can be reasonably sure will never appear in your text normally. Than after importing to the target, change those back to "".

It's a kludge, yeah, but from what i remember, those carriage returns make XML go crazy (at least in a Filemaker context). So i decided it was best to just avoid them.

J

[DABrad]

Sorry for the LONG delay in replying. Thank you much for your help.

Interestingly, I created an import/export script that does exactly what you suggested. I couldn't find any other solution. It does seem klunky though, and I hope that no more than 2-3000 records needs to be exported at a time. I guess I should set a limit.... nah, too lazy. Just let it break. :-)

It also may be a failure on my part not implementing a correct many-to-many relationship schema. This one relationship requires keys to be separated by returns in their respective fields.

[QuinTech]

Just let it break. :-)

Developer's rule #1, right? Don't fix it until it breaks!

This one relationship requires keys to be separated by returns in their respective fields.

Ooooh, yeah... that's bad. I suppose you've already weighed the pros and cons of taking the time to change over to a proper join table structure, but let me add another vote to the "PRO" column here. This is one thing i would DEFINITELY fix before it breaks, because when it does, it may be exponentially harder to fix it than it would be if you did it now.

J