The 9.0.0.1235 dbunload generates a "Check View definitions" that
creates and sets a global variable called "view_not_found".

What's the story here? There are no subsequent references to that
variable, no mention in the Help or in the groups.

Breck


--
bcarter (AT) risingroad (DOT) com
Mobile and Distributed Enterprise Database Applications
www.risingroad.com

That variable has been part of the reload.sql file for some time.
I can get it to show it's face whenever I use the -j dbunload option.

If you have no views, but have specified the -j switch there will not
be any 'other' mention to it.

Errors are checked for with this block of statements

-------------------------------------------------
-- Check view definitions
-------------------------------------------------
GRANT CONNECT TO "DBA" IDENTIFIED BY ENCRYPTED 'yadayadayada'
go
CREATE VARIABLE view_not_found INT
go
if object_id('DBA.v_x') is null then
select 1 into view_not_found from "DBA"."v_x"
end if
go
if object_id('DBA.v_y') is null then
select 1 into view_not_found from "DBA"."v_y"
end if
go
commit work
go

When I have no views defined (but have specified -j) no views get enumerated
and none of the

"if object_id( <view_name> ) ... "

test blocks are built.



Are you saying ASA 9 just creates it even when there is no -j switch
invoked?

Either way I don't expect this causes any problems.


"Breck Carter [TeamSybase]" <NOSPAM__bcarter (AT) risingroad (DOT) com> wrote in
message news:ctcjtvg4pinl609cbnr0eilr8ls7s2s32o (AT) 4ax (DOT) com...

No, it's generated as a byproduct of using -j nnn. My point is that
this generated code *does nothing*, it *has no purpose* whatsoever,
because it is just setting a variable that is not used anywhere. So
what is the point of it? That's my question

Breck The Suspicious

On 12 Dec 2003 10:39:10 -0800, "Nick Elson"
<no_spam_nicelson (AT) sybase (DOT) com> wrote:

--
bcarter (AT) risingroad (DOT) com
Mobile and Distributed Enterprise Database Applications
www.risingroad.com

YES I think that is what I said.

Further it only created when nnn >= 2.


It will.

Just add some views [nested or otherwise] and it obviously DOES have a
purpose! Or are you seeing a different behaviour than I?

Your proposition is based upon the fact that your usage is asking
for a feature you have no need for. The fact that causes no
serious failure and only puts out a harmless statement should
not be a big concern. <just my opinion/> Go ahead and
submit it as a bug if you want ... but ... I expect you are the
first person to every read the reload.sql file and felt a need
to point that out ... 1st time in probably 8+ years.

From past experience (5,6,&7) and from explicity testing 8.0.2 and 9.0
there is no new [mis-]behaviour here. This feature behaves as it
always have under the 3 states I tested

-j 0
-j 1
-j 2 [assumidly this test is sufficient for any nnn > 2 too]

and with and without views defined.



"Breck Carter [TeamSybase]" <NOSPAM__bcarter (AT) risingroad (DOT) com> wrote in
message news:ut9ktv051lei17o05cbpjr4am0jml755m7 (AT) 4ax (DOT) com...

Chill, Nick, I didn't have a "proposition", I was asking a question

....which didn't exactly get explicitly answered, so I ran a test where
-j nnn was not set high enough to deal with the circularity, and lo
and behold, yes, the statements *do* have a purpose... they *fail* if
one of the views doesn't exist. Which is good. And stupid of me, not
to notice how the code actually *worked*

(but gosh, you have to work hard at creating views that need -j nnn,
don't you? You have to create them, and then drop and recreate them in
the reverse order so they get unloaded in the reverse order. Who
*does* that?

Unfortunately, those statements in reload.sql *ALSO FAIL* if there is
no problem with any of the views, but if there is a procedure with the
same name as a view. The call to object_id() fails with an error
message "Select returns more than one row" if you call it for a view
that has the same name as a procedure, or a trigger, all of which is
legal in SQL Anywhere but not ASE.

IMO object_id() should never ever be used, except in environments that
are truly Transact SQL compatible.

All of this came about when trying to deal with the *other* problem
with dbunload: that -j nnn does not help if a view refers to a
procedure in the FROM clause since procedures follow views in
reload.sql... that got posted in the futures ng.

Breck

On 12 Dec 2003 16:20:12 -0800, "Nick Elson"
<no_spam_nicelson (AT) sybase (DOT) com> wrote:

--
bcarter (AT) risingroad (DOT) com
Mobile and Distributed Enterprise Database Applications
www.risingroad.com

My label says "Serve at room temperature" so no need to chill.

Perhaps, but it can happen through normal schema maintenance.

Definitely an oversight worth reporting ... The thread about circular
references should include that point too ... since anybody looking
into that will be in good position to address the non-unique name
problem too.

No -j does not address that problem the implementation never
anticipated that feature.

A simple solution to that problem is the technique of writing out
stubs ahead any possible references. Something somewhat akin to
prototypes in ANSI C ... Such a mechanism could entirely replace
all need for -j or any parsing necessary to build dependency trees.
But that would need to be taken under advisement.




"Breck Carter [TeamSybase]" <NOSPAM__bcarter (AT) risingroad (DOT) com> wrote in
message news:al4mtvosgi3ga4b6loseq3p1r44tgvdmrt (AT) 4ax (DOT) com...