Re: ASA 11 Alter table statement causes Assertion failed

[Unknown]

This is a little odd. The assertion goes away if I remove
the "varchar(14)" term and it does not seem to be related
to some orphan page or so (since a rebuild does not
correct the problem). If I also remove the keyword
"not", alone, this goes away.

There are a couple of obvious workarounds in all of
that.

If this is extremely urgent for you you should probably
open up a support case to identify your business
requirements and the urgency for any final fix.

In the meantime I will let engineering know about this.

"Jesse" <JGig...@Needles.com> wrote in message
news:48e62f33@forums-1-dub...
> We are running SQL Anywhere 11.0.0.1490 and when running a simple Alter
> Table statement in Interactive SQL, an Assertion Failed message occurs.
>
> The statement we are trying to run is:
>
> Alter table names modify car_phone varchar(14) default '' NOT NULL;
>
>
> The full error is:
>
> *** ERROR *** Assertion failed: 201501 (11.0.0.1490)
> Page for requested record not a table page or record not present on page
> Connection terminated abnormally
>
> This statement works fine in SQL Anywhere 9 and SQL Anywhere 10.
> It did not work with the initial release of SQL Anywhere 11 nor the
> current
> EBF (1490).
> Performing an external unload/reload on the database didn't help.
> We've also tried it on Windows 2008 Server (x64) as well as 32-bit
> versions
> of Vista SP1 and XP SP3, all with the same results.
>
>
> I've reduced the database to the minimal amount of tables, columns,
> indexes
> and data and attached it to this post.
>
> I hope someone can help us with this. We have many clients that we'd like
> to recommend SQL Anywhere 11 to, but need to get this resolved first.
>
> Thanks,
>
> Jesse
>

[Ivan T. Bowman]

This problem is fixed in build 11.0.0(1514) and later. Thank you for
bringing it to our attention.

For specific structures of table schemas and indexes, it was possible for an
ALTER TABLE statement to generate an assertion failure error when rebuilding
indexes. This has been fixed. As a workaround for this problem you could
drop indexes on the table before the ALTER and re-create them afterwards (or
alternatively use one of Nick Elson's proposed workarounds if they apply).

The problem was related to changes (new to 11.0.0) that allow parallel
execution of the sorting component of index building. My apologies for the
impact this issue has had, and thank you for providing a simple repro.

--
Ivan T. Bowman
SQL Anywhere Research and Development

"Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@> wrote in message
news:48e65232$1@forums-1-dub...

[Jesse]

We are currently using a workaround, but feel much better now that we know
the issue is fixed in a future build.
Thank you for your prompt attention to this matter.

- Jesse

"Ivan T. Bowman" <ibo...@ianywhere.NOSPAM.com> wrote in message
news:48eb4b79@forums-1-dub...