Re: Can I override the table my program looks at?
Posted in 1994
Bill I am not sure if I quite understand the use of the work "file" in your message. If you are refering to tables, you can prepare and declare a different cursor dynamically by creating a string with the proper table name. If you are refering to a file as a regular data file and need to be able to get ahold of each file and process them, we do this by running the ls command from 4GL and sending the output to a file, then use that file as an unload file and load the data into a single column table and voila, the file names are available, now it is a matter of reading the contents of the file, if unload format, then it is trival, if not, load the file into a table with a single large character column and parse each line with code. If it is a combination of a data file goes with a specific table, we have a table with the data file names and the appropriate SQL statement to load the file, get the file names using the method above, the lookup the SQL load statement in the table using the file name, then run the load command to load the data into the correct table. Sounds like a lot to set up but once done, it is easy to add other files to be loaded. Hope this helps. -------------------------------------------------------------------------------- Paul Watje SPAMIS Data Center paulw@spamis.jcdc.eta.gov Largest Informix Shop Voice: (800) 598-5008 in San Marcos, TX FAX: (512) 396-6600 P.S Not my original idea, "borrowed" from Cheryl Stukey who is someplace in Atlanta On Mon, 18 Jul 1994, Bill Dixon wrote: > In article <1994Jul15.173218.8016@bcarh54a.bnr.ca>, > Joel Leonhardt <joell@bnr.ca> wrote: > >Here's one solution, albeit an ugly one: make a short unix script that > >edits the COBOL "source" code and replaces TABLE1 with TABLE1A. Then your > >changes are not lost when this "source" is regenerated; you merely re-run > >your unix script before the COBOL compile. > > > >Good luck. > > I must not have made myself clear. We need to be able to run a single > program, against an unknown number of files, all with the same layout but > different names. It is not practical to create a separate program for > each file, partly due to the large number of potential files, but also > because we do not know in advance how many files there will be, or what > their names are. (These are work files, primarily.) > -- > Bill Dixon >