>>>I am working on an import class. What this class will do is:
>>>
>>>(1) allow the user to select an import type
>>>(2) allow the user to select a file from that import type
>>>(2) from that import type create some temporary tables and structures unique to that import type
>>>(3) append the import file into the newly created temporary tables
>>>(4) do some file processing unique to that import type
>>>
>>>
>>>I'm running into design problems trying to make a generic class that can handle any import type and unique file processing for that type. How I had it set up originally is have a table with an import type field, a structure memo field (in which I have a list of table structures and names for that type), and a process memo field (in which I place the custom processing code for that import type.
>>>
>>>I'm having all sorts of problems with macro substituting structural arrays for the creating of tables and the same for processing routines. I really didn't want to hard code this information for each new import type we get.
>>>
>>>Perhaps my whole approach is wrong? Anyone have any ideas on a better approach to this type of class? Any input/discussion would be much appreciated...hey, I know you all like theoretical discussions ;).
>>
>>I wrote similar import class for one project and after some testing I ended up with 3 basic import choices: fixed length text file, delimited text file (with flexible delimiter/separator character), table with fixed structure. System accepts input from various sources, most of them structured ASCII files (choice 1 or 2), but some files are really difficult to be imported immediately (e.g. prn files). These files preparated manually by myself into table with fixed structure and then processed by the class (choice 3).
>
>
>The problem I see with that type of implimentation is the hard-coding of structures and such. Any time you would need to add a new import type you will need to modify your class and redistribute the executable. I am trying to develop something generic enough so that you can specify everything you need in a table.
>
>I haven't been able to get the create table command to work with macro substition, e.g. Create table import1 (&v_import.struct). It has all sorts of
problems. But, at least that looks doable in some form if I work out all the bugs. My biggest problem is coming up with a generic way to deal with file processing related to each import. If I have stright commands I need to do (for example REPLACE ALL v_import.name with UPPER(v_import.name) then I might be able to place this code in a memo field and macro substitute it. However, if I need any type of looping, do...while, for...endfor, etc., I can't use macro substitution.
>
>This whole class is becoming a lot more complicated than I expected :).

As a absolute fan of all kinds of generic solutions, I tried a lot of times to find similar ways to solve problems you did. In most cases the only practicable way was to use a technique Steven Black lately described in a journal. He called it "Hook Operation" which means to use a Design Pattern that fires either before a method starts, while it processes or after it has finished. If this HOOK finds a apropriate Dataset in a Table for Meta-Data it can start external Procedures or Objects. With this technique you can enhance Classes, Objects, whole Software-Packages at runtime. Sure you have to hard-code the various Types of Import-Procedures but you do not have to change your Software if such an enhancement is necessary. The only thing you have to do is to furnish the add-on and insert the necessary start comand in the metadata-file.

Regine