Note that the original view has two identical references to the same table in the FROM clause:

work_order_part_part as wopp

work_order_part_part as wopp

(tip: use explicit html pre tags for code in comments)

The following script runs without error on 17.0.9.4882

create table part ( 
prt_id integer NOT NULL DEFAULT autoincrement, 
prt_cd char(30) NOT NULL unique, 
PRIMARY KEY (prt_id) ) 
go

create table work_order ( 
wk_ord_id integer NOT NULL DEFAULT autoincrement, 
wk_ord_no char(30) NULL, 
primary key (wk_ord_id) ) 
go

create table work_order_part ( 
wk_ord_id integer NOT NULL references work_order on delete cascade, 
wk_ord_prt_key_no smallint NOT NULL, 
PRIMARY KEY (wk_ord_id, wk_ord_prt_key_no) ) 
go

create table work_order_part_part ( 
wk_ord_id integer NOT NULL, 
wk_ord_prt_key_no smallint NOT NULL, 
wk_ord_prt_prt_no smallint NOT NULL, 
prt_id integer references part, 
primary key (wk_ord_id, wk_ord_prt_key_no, wk_ord_prt_prt_no) )
go

alter table work_order_part_part 
add constraint work_order_part 
not null foreign key (wk_ord_id, wk_ord_prt_key_no) 
references work_order_part ( wk_ord_id, wk_ord_prt_key_no ) 
ON DELETE CASCADE 
go

create view view_test as 
  select 
    wo.wk_ord_id,
    wo.wk_ord_no,
    p.prt_id,
    p.prt_cd 
  from
    work_order as wo join work_order_part_part as wopp on
      (wo.wk_ord_id = wopp.wk_ord_id),
    work_order_part_part as wopp join part as p 
go

SELECT 'create view view_test is OK';

create view view_test_2 as 
  select 
    wo.wk_ord_id,
    wo.wk_ord_no,
    p.prt_id,
    p.prt_cd 
  from
    work_order as wo 
    join work_order_part_part as wopp on (wo.wk_ord_id = wopp.wk_ord_id)
    join part as p on (wopp.prt_id = p.prt_id)
go

SELECT 'create view view_test_2 is OK';

SELECT @@version;

create view view_test is OK   
create view view_test_2 is OK   
17.0.9.4882

> We know a cross join when we experience one

LOL!

The two separate references to wopp in FROM clause is (almost) never seen in practice, and I have no idea how SQL Anywhere interprets it... but perhaps is overrides The Nightmare That Is Cross Join :)

it simply performs a one-to-many join of "wo" to "wopp", and a one-to-one join of "wopp" to "p".

Well, if so, why do you need a comma operator then?

Isn't that simply wo -> wopp -> p, so just two joins, so no need for a list of table expression?

However the join structure in our example with join keywords, and join conditions when necessary, performs as inner key joins

Well, then I would write that as INNER JOINs, so nobody needs to know how it performs...

Hm, I do use CROSS JOINs rarely - but they are clearly defined, so I don't see the nightmare here...

The "create view" statements were never the problem, nor was "select * from <view>". The problem was the "unload" statement within the block as shown in my original post. It worked on some versions of SQL Anywhere, and blew up on later versions.

Indeed we don't need a comma here, and could simply join "a to b to c". In this example we should have. However we have Where clauses that join in many more tables where (I argue) the pattern with repeated table names (and aliases) results in easier to understand join lists. For example, "a to b", "b to c", "b to d to e". This example could also be written as "a to b to c", "b to d to e" - the "b" is repeated, but I think adds to readability and clarity.

Well, I guess we have different ideas of readability here, I generelly prefer one single occurence of a particular table instance (aka table alias) in the FROM clause and prefer to express the join condition by clearly telling which aliases are joined to others. Sometimes indenting the table names does help...

Bt of course YMMV.

As to the basic question, if the view is correct SQL Anywhere syntax (and the comma operator surely is valid), the unload should work, as well, so I'd consider that a bug.

OK, but the create view did have the syntax error when using my prior guesswork at the schema... sigh :)

The problem can be demonstrated by wrapping the select with a simple unload (no view, no variable):

unload 
  select 
    wo.wk_ord_id,
    wo.wk_ord_no,
    p.prt_id,
    p.prt_cd 
  from
    work_order as wo join work_order_part_part as wopp on
      (wo.wk_ord_id = wopp.wk_ord_id),
    work_order_part_part as wopp join part as p 
to 'c:\\temp\\x.txt';

Could not execute statement.
Column 'prt_id' not found
SQLCODE=-143, ODBC 3 State="42S22"
Line 1, column 1

I don't know if this FROM clause does what you want, but it eliminates the syntax error:

unload 
  select 
    wo.wk_ord_id,
    wo.wk_ord_no,
    p.prt_id,
    p.prt_cd 
  from
    work_order as wo 
       inner join work_order_part_part as wopp 
          on (wo.wk_ord_id = wopp.wk_ord_id) 
       inner join part as p 
          on (wopp.prt_id = p.prt_id)
to 'c:\\temp\\x.txt';

If that FROM clause does NOT do what you want, I highly recommend you re-code the FROM clause

(a) without mixing INNER JOIN and comma operators

(b) without coding the same table name more than once and

(c) without using the default KEY join operator.

The nightmares came during my SQL childhood, when the comma join was the only game in town, and an accidental omission from the WHERE clause transformed the comma into a cross join. It was the very first SQL question I asked on a CompuServe forum, and Joe Celko answered it.

Re "prefer to express the join condition by clearly telling which aliases are joined to others": I like to avoid specifying Join conditions when SQL Anywhere can figure them out (i.e. only one way to key join), and by repeating the table/alias, I can see what table joins to what other one without a join condition. It seems to me that SQL Anywhere is just ignoring duplicated table/aliases in the FROM clause. Get your alias wrong, and you have a cross join.

I remember, and don't miss, the old "join conditions in where clause" days, myself.

Thanks to both of you, Volker and Breck. I think we covered it, and I will think more about your viewpoints. One bottom line is that I agree with Breck that there is a bug here. We have already worked around it. Hopefully the bug gets put in a hopper, although I wouldn't call it an urgent bug.