Filemaker can not export to *.dat files it seems...
Do I need a plugin? are there even any available ?
Are theere other ways in achieving this ?
StringSpaces( text ; requiredLength )
len = length (text);
spaces = " "; //make this the max number of spaces you'll ever need to place, I made it ten here
sub = left ( spaces ; requiredLength - len )
if ( len > requiredLength ; "ERROR" ; text & sub )
.DAT doesn't really have a universally recognized/delimited format, thus what is actually contained in any given .DAT file can vary widely between applications.
You CAN save a file titled .DAT in a script by setting the path (with filename) and .DAT as the extension, but you will always be limited to the raw formats of the delimited or specialized files that filemaker supports.
IE, I can save a CSV file as a .DAT file.
If you want to mimic the format of an existing DAT file, you theoretically could export the contents of a calculated text field as a .DAT named .TXT file using export field contents. You would just need to calculate the contents of the text field to mimic what the output needs to look like.
Mike Beargie wrote: You CAN save a file titled .DAT in a script by setting the path (with filename) and .DAT as the extension, but you will always be limited to the raw formats of the delimited or specialized files that filemaker supports.
Mike Beargie wrote:
This is wrong. You can export as XML and use an XSLT to transform to the desired target format.
Nothing is impossible in FileMaker.
I find that for creating any type of file that is not natively supported , the you can't go past the Base Elements plugin (by Goya) , it's simply brilliant.
Using this plugin, you create the content of the file either into a field or a variable, and when you are ready to create the file , simply call the BE_WriteTextToFile function. I use this for writing Direct debit files for online banking, html reports, even KML google earth files, all from FileMaker. Using this method you can also embed control characters , or anything else that needs to be in there. In other words , you can create any type of file you like, but it's up to you to create the content using filemaker scripting and caculations.
Martin, this is not wrong. You CAN do what I described.
Attached is an example as proof of both methods I described:
1) Exporting a found set based on an existing delimited format (.tab) renamed as .dat.
2) Exporting field contents of a text field to a .dat file
As noted for method two, if you can calculate the complete format/content of the dat file you are trying to reproduce (headers, data, etc..), then you can export a text field as a dat file.
I'm not discounting the XML/XSLT option (which is complicated to learn, and still adheres to a very specific markup structure that might not get what is needed in the .dat format), or the baseElements option outlined as well. But I am saying it IS possible to do what Tony wants to do above in native filemaker. I know because I've done the exact same thing since FM9 with a similar non-filemaker format.
You wrote: "but you will always be limited to the raw formats of the delimited or specialized files that filemaker supports". Just this point is wrong.
XML/XSLT import/export is a native technology in FileMaker since version 6.
The xsl:output element supports three methods: xml, html, and text. The text method allows to output any sequence of Unicode characters as long as these are in the allowed XML character set. So it is not limited to markup.
One of the big advantages is that you don't have to implement additional (calculation) fields just for exporting and having to clutter your database model. The problem is that a calculation must be either stored per record or as a global. Which limits somewhat the way data can be exported (in FM 12, ExecuteSQL() might be of some relief).
With XSLT, however, one is much more flexible. One can address data record-wise or aggregate by any type of record (and field) group as one wishes. E.g. group always two, or three, or x records. Group the paired or impaired. Change order virtually. Combine and aggregate fields and data on the fly.
It's a much underestimated technology. And worthwile to learn at least the basics.
If you need to create such a thing (look at the slight differences) for ten-to-hundredthousands of records without blowing up your DB, then XSLT will be your friend:
000010228 FMT L BK
000010228 LDR L -----nam--22-----uu-4500
000010228 008 L ------s1970----xx -----------------eng--
000010228 020 L $$a0-471-83495-5
000010228 040 L $$aETH-HCI$$beng
000010228 099 L $$alg$$lCLICAPS
000010228 245 L $$aAquatic Chemistry$$bAn Introduction Emphasizing Chemical Equilibria in Natural Waters$$cW. Stumm, J.J. Morgan
000010228 260 L $$aNew York$$bJohn Wiley & Sons$$c1970
000010228 300 L $$a583 S.$$c23,5 cm
000010228 700 L $$aStumm, W.
000010228 700 L $$aMorgan, J.J.
000010228 940 L $$aZU4125005$$cBook$$d56$$fE33$$h386 B$$j100760$$n10228
000010238 FMT L BK
000010238 LDR L -----nam--22-----uu-4500
000010238 008 L ------s1970----xx -----------------ger--
000010238 020 L $$a3-400-00001-9
000010238 040 L $$aETH-HCI$$bger
000010238 099 L $$lCLICAPS
000010238 245 L $$aKernresonanzspektroskopie$$bStudienbuch für Studierende der Chemie nach dem Vordiplom$$cThomas Clerc, Ernö Pretsch
000010238 260 L $$aFrankfurt$$bAkad. Verlagsgesellschaft$$c1970
000010238 300 L $$a182 S.$$c22 cm
000010238 700 L $$aClerc, Thomas
000010238 700 L $$aPretsch, Ernö
000010238 940 L $$aZU4106420$$cBook$$d56$$fE33$$h316 C$$j100784$$n10238
000010240 FMT L BK
000010240 LDR L -----nam--22-----uu-4500
000010240 008 L ------s1970----xx ----------------------
000010240 040 L $$aETH-HCI$$b---
000010240 099 L $$lCLICAPS
000010240 245 L $$aLes règles de Woodward-Hoffmann$$cTrong Anh Nguyên
000010240 260 L $$aParis$$bEdiscience$$c1970
000010240 300 L $$a196 S.$$c23 cm
000010240 700 L $$aNguyên, Trong Anh
000010240 940 L $$aZU4116974$$cBook$$d56$$fE33$$h200 E$$j100792$$n10240
000010252 FMT L BK
000010252 LDR L -----nam--22-----uu-4500
000010252 008 L ------s1970----xx -----------------ger--
000010252 040 L $$aETH-HCI$$bger
000010252 099 L $$lCLICAPS
000010252 245 L $$aAtom$$bStruktur der Materie$$chrgs. von Christian Weissmantel... [et al.]
000010252 260 L $$aWeinheim$$bVerlag Chemie$$c1970
000010252 300 L $$a856 S.$$c22 cm
000010252 700 L $$aWeissmantel, Christian
000010252 700 L $$aLenk, Richard
000010252 700 L $$aForker, Wolfgang
000010252 700 L $$aLudloff, Rudolf
000010252 700 L $$aHoppe, Johannes
000010252 940 L $$aZU4103790$$cBook$$d56$$fE33$$h333 E$$j100815$$n10252
That makes much more sense now, thanks for clarification.
Most developers I've known are scared off by the steep learning curve that XSLT transformations require to learn. While I myself have picked up the basics, I haven't personally had a use for it where it is preferred over running SQL server scripts that aggregate data the same way as you describe above for massive exports. Since the massive data sets I work with are already stored in SQL server and accessed via ESS, we just run any complex (IE backup or summary reports) mass-data functions on the SQL server itself, or via Execute SQL (the script step, not the function).
For future reference and benefit, do you know of a good whitepaper that explains the basics of exporting as XML with an applied XSLT?
FileMaker Pro 6 Developer's Guide to XML/XSL
5 stars out of 5.
Still valid for higher versions of FM Pro.
For XSLT in general: Michael Kay, XSLT Programmer's Reference
thanks for all the input.If DAT files are just strings of text, I will then build them from the individual text files via a calculation.
However, still one Question :
If a line in the dat file is built up by for instance :
field1 : 10 characters (for instance all A's)
field2 : 5 characters (for instance all B's)
the result will look like : "AAAAAAAAAABBBBB" (if all characters are used).
However, field 1 can be only 3 characters, so then te result needs to be :
"AAA BBBBB" (==> notice the 7 spaces after the AAA)...
Is there a simple way for the field1 to be returned AAA + 7 spaces ?
How to tell Fiemaker to always complete the text to 10 characters by adding speces behind?
thx, mike !
no trouble, you could also tie that to a script trigger to automatically format fields in advance upon user entry.
Another way would be to do field level validation, but you're users would probably try and hunt you down with torches and pitchforks if they had to manually enter the correct number of spaces. I would however recommend field level validation on strings that are too long in advance, rather than the "ERROR" returned by the above.
Retrieving data ...