Steve,
I'll have a look at that possibility. I had thought of using another
filemaker file to receive the data as imported from the primary system,
then exporting that as the csv file. In that way by using filemaker's
import features I can separately script where all the data is entered.
I'm guessing 3 imports, one for the 'Header', one for 'Data' then one
for the 'Footer'. Then, export that data as a csv file. It all looked a
little cumbersome but I'll investigate it some more. Thank you for your
interest and time.
Lee Mills
Steve Cassidy wrote:
On Jul 9, 2009, at 12:38 AM, Ross Dickson wrote:
Another approach is to assemble all of the data with its formatting
requirements in a global text field. Add the header and footer
information, and export the global text field from one record.
Convert the vertical tabs in the exported text file into returns with
a file management plug in.
Yet another approach, and one I've used when faced with a requirement
for multiple exports of this type from different tables (actually
files -- this was pre FMP7 days), is to use a temporary file.
The temporary file simply has as many fields as you need columns in
the export. You set up your export by creating a first (header) record
and populating the fields appropriately for the header. Then import
your record set. Then create a final (footer) record and populate
appropriately. Then export and finally delete the found set. This can
all be scripted of course.
The biggest difficulty with this is field/data types. I made all the
fields in the temporary file of type text. Then made sure I populated
the fields with already-formatted data. A second problem is that you
have to carefully consider how it is going to work in a multi-user
situation. I'm sure this approach would be simpler in FMP10 than it
was back in FMP6.
Given that this is becoming a major part of your client's business,
such a 'temporary' file might be useful if made 'permanent'. I could
envisage a situation where you have a pair of related tables: export <
export_lines. The export table (with fields for export date, user,
perhaps export destination, etc.) would have one record per export and
all the export lines would be related to it. You would then be left
with an audit trail that shows who did the export and when as well as
the exported lines (including header and footer). In my experience,
this can be very useful -- especially in this kind of situation where
you have to be very careful not to send off the same data twice.
Just a thought!
Steve
--
