Re: Need to determine which version of a file a program has to work with

[CRPence <CRPbottle@xxxxxxxxx>]

On 3/4/11 10:54 AM, Charles Wilt wrote:
> I've got a need for a program that can work on two different
> versions of a file. Specifically, in one version of the file a
> particular field is 10a, in the other it's 7p00.
>
> The program will be using SQL, so level checks aren't an issue. But
> I still need to know which version I'm dealing with so I know which
> statement to run.
>
> We've come up with the following methods to determine which version
> of the field is available
> 1) IBM API's

  Already using SQL, so why go to a non-SQL API?  I actually had long 
ago written a ColumnExists procedure to resolve similar [the old TABLE 
was missing the field] for a utility upgrade\conversion, using the List 
Fields (QUSLFLD) API.  As I recall the biggest negative for me was that 
the API was one of those requiring User Space APIs versus allocated 
storage; i.e. creating a named object that is either remains in QTEMP 
for reuse or is deleted each time, and for what value.?

> 2) SQL Describe

  Already using SQL, seems good to go.  No external *UsrSpc as storage 
location.  If there is a prepared statement with the column, consider 
describing the statement instead of the TABLE when that might be better 
to limit the data.

> 3) Looking at SYSCOLUMNS

  Why run a query?

> Any pros/cons to the above?
>
> Does anybody have any additional ideas?

  Perhaps... Is there really any requirement to know the difference? 
There is implicit casting between the two types, and explicit casing is 
legitimate to get a consistent type into the non-SQL program variables.

Regards, Chuck