dynamic import types

[Bruce Easton]

Yeah - like export, referencing the same file would only work if you use 
different aliases.  So if I had a screen where I capture the full file 
path and either "csv" or "tab" (to use two of your types), and those 
were sent to a called table via global vars in an input table, then the 
called table could capture from the appropriate import file, but you'd 
have to make a set of assignments for each file type:

Then: declare extern api_data_format
      If:
Then: declare extern impFile
      If: api_data_format ne "csv"
Then: goto trytab
rptidc If:     'csv file processing
Then: import word idc = (impFile)
      If: not idc
Then: goto closidc
      If:
Then: lookup newdat = impdata@  r=free  -e
      If:
Then: newdat(1)=idc(1); newdat(2)=idc(2); goto rptidc
closidc If: newdat
Then: close newdat
      If:
Then: end
trytab If: api_data_format ne "tab"
Then: end
rptidt     'tab file processing
Then: import ascii idt = (impFile)  f=\t r=\n
      If: not idt
Then: goto closidt
      If:
Then: lookup newdat = impdata@  r=free  -e
      If:
Then: newdat(1)=idt(1); newdat(2)=idt(2); goto rptidt
closidt If: newdat
Then: close newdat
      If:
Then: end

I guess a possible advantage would be if there is a variation in the 
layout between file types, then you'd need the extra set of assignments 
anyway.  And if you had several different clients who supplied the same 
data, but with differently ordered layouts, I suppose something like the 
code above could work if, for the free-record lookups, you declared an 
array against it, and before assigning, referenced a filepro file that 
would be keyed by client and provided the hash of field assignments for 
each client and field.  In that case, you could capture and pass the 
client code into here and still run this same code.  I guess also in 
such a case the assignments would be more like:

Then: lookup reffile = (clihash)  k=(clicode) i=A -ng
      If: not reffile
Then; goto dunrefl
      If: reffile(1) ne clicode
Then: goto dunrefl
Then: nn=reffile(3)
If: reffile(2) eq "1"
Then: arr[nn]=idc(1)
If: reffile(2) eq "2"
Then: arr[nn]=idc(2)
Then: getnext reffile; goto refloo
dunrefl
.
. etc. , where "arr" is dimensioned against "newdat", where nn would 
loop (getnext) from 1 to the highest field# in the reference file for 
the client (in say field 3 there) and would indicate the target field to 
be assigned.

reffile could look like:

Client(1)    imp fld#(2)   asign_to(3)
XYZ          1              1
XYZ          2              3
ABC          1              3
ABC          2              2

Or, like you say - go with separate called tables.





On 4/24/17 7:21 PM, Brian K. White via Filepro-list wrote:
>
>   If: api_data_format eq "csv"
> Then: import word idf = (impFile)
>   If: api_data_format eq "pipe_delimited"
> Then: import ascii idf = (impFile) f=| r=\n
>   If: api_data_format eq "tab_delimited"
> Then: import ascii idf = (impFile) f=\t r=\n
>
>
> import ascii idf = (impFile) f=| r=\n
>                             ^
> Merge name incompatibility.
> Word processor or spreadsheet merge has been given two different names.
>
> Dangit, is there a nice way around this or do I have to give up on 
> this idea and just pick one?
>
> I mean yeah I suppose I could write 3 tiny tables and CALL the right 
> one, or write out a temp version of the full table and chain to it or 
> something, but I mean short of unnecessarily Goldbergian things like 
> that. Actually the call idea might not be too bad after all, as long 
> as no one else is CALLing this table itself, which I am pretty sure 
> about but not 100% sure about. It does contain some comments that 
> imply passing long variables back to a parent, but that could just be 
> poorly written comments, especially since they appear above a stack of 
> explicit DECLARE LOCAL, hello, local... not extern or global or 
> unspecified. Anyway not interesting, sorry.
>
> Then: declare fpit, fpid
>   If: api_data_format eq "csv"
> Then: fpit = "word" ; fpid = ""
>   If: api_data_format eq "pipe_delimited"
> Then: fpit = "ascii" ; fpid = "f=| r=\n"
>   If: api_data_format eq "tab_delimited"
> Then: fpit = "ascii" ; fpid = "f=\t r=\n"
>   If:
> Then: import (fpit) idf = (impFile) (fpid)
>
>
> import (fpit) idf= (impFile) (fpid)
>        ^
> Process contains a syntax error at position indicated.
>
> ...I guess not that way ;)  I kind knew that wouldn't work, just worth 
> a shot since it was easy to try.
>
> ... well, I am receiving these data files via php cgi script, so I can 
> do the translation both ways in there, the same way I'm already doing 
> for line endings. Take in whatever, feed only one consistent format to 
> filepro. This would just be more of the same. So I guess it's no loss 
> to pick one format for use inside the table after all. The exterior 
> facing api would still allow any, which is all that matters.
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus