DSXchange

What about jobs and scripts? I think that is worse. I tend to over comment in scripts and sometimes BASIC code so it is easy to see my code in other people's work. To pawn other people's work as your own is worse. It is expected that others will reword something expecting it to be more easily unders...

I don't mind as long as it is just Craig. Mail it to me.

Why not?


I agree with Craig. This should work.

The job number is 2417. You could do a

SELECT * FROM DS_JOBS WHERE JOBNO = '2417';

To find out which job it is then try to fix this one job.

I think Vincent is on the right path. In Reporting Assistant's doc_tool.mdb. The columns are stored in DSColumns and in DSProperties. You could select column names not in the list from the other job.

Send me a copy. I will give you my opinion.

Thanks Ray.

Sure the lex parsimoniae (law of succinctness). http://en.wikipedia.org/wiki/Occam's_razor Easy for us simple minded folks.

You could use a parameter like #SqlStmt#. You could also change utility hash file read to do an openpath to the directory where your script was. Next the key is the filename of the SQL file.

This is not a simple solution but I think you can figure it out.

I like the simple ones.

I land them into a hashed file just like this post http://www.dsxchange.com/viewtopic.php?t=105239

Ray is correct. Most of the time I add -c.

You need to quote it right as well to get the arguments correct. Under the covers these command are calling the execute command in BASIC.

You need ";" at the end of your SQL statement.

I land the values in a hashed file. I use the utility hash read routine to read it into a variable in a sequence to load it into a parameter.

#!/bin/ksh # 500mb find . -size +500000000c -exec ls -l {} \; The find command has lots of options. The . is the directory it starts to look in. You cn make this / to look in every directory on the system. Usuaully you need to be root to do this or you get lots of errors. The -size says r...