dynamic import types

[Bruce Easton]

Small correction - left out an important label ("refloo").

On 4/24/17 11:47 PM, Bruce Easton via Filepro-list wrote:
> 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
refloo     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
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>



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