Sometimes RAM errors cause symptoms that look like disk errors. Remember, EVERYTHING goes through RAM... SQL Anywhere doesn't actually see data on the disk, it only sees data after it's been copied to RAM by the O/S, BIOS, device drivers and disk adapters.

RAM errors are particularly evil since continued use of bad RAM can CAUSE true data errors, and can in some cases cause complete destruction of data even though the physical disk drive is flawless.

If you suspect a RAM error, stop using the database immediately and run a full diagnosis of the RAM. With commodity hardware, it's often easier/cheaper just to swap out the RAM, or swap computers.

We are able to reproduce an issue that results in the assertion error 201200 "Did not expect to continue row segment". Its reference number is QTS 674549. In our case, that recursive clause of a recursive select statement first cause the non-fatal asssertion error 111706 or 111707 and then the fatal assertion error 201200 when trying to write a subsequent row segment.

For example: The below recursive select does a string concatenation z||c and exceeds the describe data type "char(10)" so it should return a SQL error but not an assertion error.

create table T1 ( a int, b int, c char(10) )

with recursive V0 ( x, y, z ) as (
    select a, b, c from T1 where  a = 1 and b = 2
    union all
    select a, b, z||c f from  T1,V0 where   T1.a = V0.y )
select *
from V0

You may check for recursive selects and/or assertion errors 111706 or 111707. To work around the above issue the corresponding result set column in the first subselect needs to be casted to a larger type, e.g.:

with recursive V0 ( x, y, z ) as (
    select a, b, cast(c as varchar(32767) from T1 where  a = 1 and b = 2
    union all
    select a, b, z||c f from  T1,V0 where   T1.a = V0.y )
select *
from V0

We are currently looking for a proper fix for this issue.

The assertion means that a database page was corrupted. The cause can be due to a software fault, or a transient or permanent corruption of the media.

Do you have checksums enabled for your database?

Is there anything in the Windows event log that would pertain to the failure?

Turn on request level debugging (server options -zr sql -zo requestlog.out) and look for the last requests. This should point you to the causing sql statement.

Got same error on recursive select. Looks like BUG in SA.