Operations like ALTER TABLE need absolute, complete, exclusive access to the table. Operations like SELECT obtain a schema lock on the table that prevent other connections from gaining exclusive locks... in this case, to prevent the other connection from messing up the schema while this connection is working with the table... hence the name "schema lock".

This is standard behavior for SQL Anywhere, and you solve it by issuing a COMMIT on the connection that did the SELECT... or in the case of Sybase Central, which is the biggest offender for holding schema locks on everything in sight, you just shut it down while doing your ALTER.

Another approach (sometimes used in production environments) is to let the ALTER TABLE sit there blocked until all other connections let go (perhaps overnight). In this case the ALTER TABLE connection has to set the blocking option to ON. That's the default: sit and wait, rather than raise the exception you saw, which leads me to believe you saw that message in Sybase Central which (I think) sets blocking to OFF so it will immediately choke when faced with a lock that blocks it from proceeding. In a production environment, you typically want blocking set on (the default) so that application connections will wait momentarily while other connections quickly update and commit stuff, rather than have connections failing all over the place when users collide.