Depends on your definition of compatible. The migration can be done. I'm in the process of converting from SQLBase to SQL Server now.
There are a number of issues you will have to address:
SQLBase has Date and Time data types natively. SQL Server has only DateTime. (Although you can define your own types.)
SQLBase reserved words SYSDATETIME and USER are replaced by SQL Server reserved words CURRENT_TIMESTAMP and CURRENT_USER.
SQL Server uses "+" for concatenation instead of "||"
Dates are not well parsed when expressed as constants. Generally best to use bind variables or quoted strings and let the compiler convert to date(time). Date constants syntax is different: instead of 2003-05-29-13.30.00.000000 you would need to use something like "5/29/2003 13:30:00.000"
Functions need to be replaced. E.g. IsNull() replaces @NullValue(). Not all functions have direct counterparts, but in the worst case you can create your own thru what is called extended stored procedures.
Date arithmetic is done with functions in SQL Server, not the simple add and subtract that works so well in SQLBase.
Security is a little more complicated. There is no counterpart to declaring public synonyms in SQL Server, so unless dbo owns the table the name must be fully qualified to use it.
The optimizer is not as good as SQLBase, but there is provision for you to provide a "hint" as to what index should be used when necessary.
Anyway, that's a start.