🚀 go-pugleaf

David Tsai <dt1n+@andrew.cmu.edu> writes:

>Do I have to do anything special to the file before I import it....for
>example, Will all subfiles will have to be in a separate file from the
>rest of the table?

this is up to you; 4d does not automatically do anything with subfile
importing that you do not code yourself.  i usually encapsulate the
entire subfile in what 4d interpretes as a text field; then i parse
out and create the subrecords myself.

>Does 4d take care of importing automatically into the subfile or will I
>have to write the special code to import data to the subfile.  I want
>this to work at the runtime level cause my client wants to be able to do
>this herself.

you will have to write code (see above).  there is no reason, though,
that you can't make the import a menu choice so that your client can
do them herself.  all you really have to do is make sure that the
import file is in the format that your import code expects.

--mike

David Tsai <dt1n+@andrew.cmu.edu> writes:

>Does 4d take care of importing automatically into the subfile or will I
>have to write the special code to import data to the subfile.  I want
>this to work at the runtime level cause my client wants to be able to do
>this herself.

Hey Dave --

*HEADACHE* is the name of this game!  Try to avoid subfiles if you can,
but I bet you wouldn't have asked the question if you didn't want an 
answer...

Unfortunately, you've got to walk through each record you want to add
to the subfile -- create it, assigne the values and then *SAVE* the Subrecord.

When you select the *parent* record, it's the current selection, and the 
*FIRST* subrecord is the curren *sub* selection, if you will.

One trick that I like to use is to make a separate data file that's all
text (7-8 fields)  and dump the data to be exported into it.  Then you
can manipulate the data as you like and put it in to the appropriate data
file.

Hope this helps.


******************************************************************************
Lauren Boyd					Department of Otolaryngology
Systems Analyst/Programmer			University of Washington, RL-30
*Go Bill!*					Seattle, Washington  98195
******************************************************************************

gnat@stein.u.washington.edu (L Boyd) writes:

[to import data into subfiles]

>Unfortunately, you've got to walk through each record you want to add
>to the subfile -- create it, assigne the values and then *SAVE* the Subrecord.

warning: you can *not* save subrecords.  a subrecord is saved when/if
the parent record is saved.

>When you select the *parent* record, it's the current selection, and the 
>*FIRST* subrecord is the curren *sub* selection, if you will.

clarification: if there is more than one record in the current
selection, the record that you are working on is the 'current record,'
not the 'current selection.'  likewise, if there is more than one
subrecord in the subfile, when the record is loaded the first
subrecord is the 'current subrecord' and not the 'current
subselection.'

>One trick that I like to use is to make a separate data file that's all
>text (7-8 fields)  and dump the data to be exported into it.  Then you
>can manipulate the data as you like and put it in to the appropriate data
>file.

i'm not really sure what you are saying here, but i do something
similar if i am importing a record that contains subrecords.  on the
import layout i include a VARIABLE that will be filled with the entire
contents of the subfile.  this variable will get all of the subfile
data concatenated together delimited with a subfield delimiter
assigned by me.  it can then be broken up on import into subrecords
and saved when the parent record is saved.

if you have a spare text field (like a comments field that is to be
filled in later by hand), it can be used for the same purpose except
that it allows you to run an update procedure later to do the parsing,
whch makes the actual import part of the process faster.

--mike