Re: SQL - Declare Global Temporary level check -- MIDRANGE-L

Vern,

 SQL gets rid of the level check issue, but it also gets rid of level
check protection!  If the SQL generated file is different in a
significant way, then I want to know about it as soon as the program
attempts to open the file, not long after things have gone very wrong! 
And if it's a bug, then it should be fixed.

 -mark

Yeah mark- recognized the name - am very familiar with it!

I was thinking that you must be trying to read the temp file with native
IO - there'd be no level check issues if you read it using embedded SQL,
as I know you know!!

Regards
Vern

-------------- Original message --------------
From: "M Lazarus" <mlazarus@xxxxxxxx>

Vern,

Ironically enough, that's just what I was doing! The DDS file exists
(you may recognize it as a Webdocs file!) and I was doing an embedded
SQL
to create a temporary subset of the file.

-mark

Hi Mark

This is what you get when you try to mix SQL and F-specs - easier just

to

use embedded SQL, I think.

Vern

-------------- Original message --------------
From: "M Lazarus"

Rob,

Yes, we did have a discussion about a similar situation. The

differnce

is that the bug mentioned there had the "external" format ID between

the

files showing the same ID (which is displayed via DSPFD), while the
internal ID was different. Here, the external ID is showing as being
different.

It was also under v5r3 and below. We have since upgraded to v5r4 and

are

current on PTF's.

-mark

But, didn't we just hash the crap out of this a few weeks back?

Wasn't

there some additional weird fluke that affecting the record format

level

check? Maybe fixed by a ptf?

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com