G
Geoff
For discussion's sake....
I've just finished developing 9 or 10 queries, (makes, appends, deletes),
that will take 14 imported ISAM files, normalize some of the nastier data,
and extract "yesterday's" business into a tab delimited file.
Now I want to automate all of it into a nightly process, so I start building
a macro and realize that I can't actually use the queries in the macro, I
have to copy the sql statements and use RUNSQL.
Here's the discussion part...
Why go through the trouble of building individual queries if you're just
going to build a macro anyway?
Why can't macro building include sql building?
Should I delete the queries, now that their sql is in the macro?
If I don't delete the queries why should I bother updating two sets of sql,
(query & macro)?
Should I always build queries and keep them updated even if I'm going to put
it all in a macro?
Remember, it's a discussion, so feel free to contribute.
Thanks!
Geoff
An Old Fogey stuck
in COBOL, trying break out.
I've just finished developing 9 or 10 queries, (makes, appends, deletes),
that will take 14 imported ISAM files, normalize some of the nastier data,
and extract "yesterday's" business into a tab delimited file.
Now I want to automate all of it into a nightly process, so I start building
a macro and realize that I can't actually use the queries in the macro, I
have to copy the sql statements and use RUNSQL.
Here's the discussion part...
Why go through the trouble of building individual queries if you're just
going to build a macro anyway?
Why can't macro building include sql building?
Should I delete the queries, now that their sql is in the macro?
If I don't delete the queries why should I bother updating two sets of sql,
(query & macro)?
Should I always build queries and keep them updated even if I'm going to put
it all in a macro?
Remember, it's a discussion, so feel free to contribute.
Thanks!
Geoff
An Old Fogey stuck
in COBOL, trying break out.