This section includes error messages for the Adaptive Server Parser.
15
Incorrect syntax near '%.*s'.
This error occurs when Adaptive Server detects a syntax error in a Transact-SQL command or query.
This error can occur when:
A keyword is spelled incorrectly.
A keyword or parameter is missing.
The order of keywords is incorrect.
You use an editor invoked from isql to write a SQL command or batch, end your SQL with “go” or another terminator, and then run the file from isql. This only causes this error in some cases.
A script that used to work no longer works after you change the sort order or the character set of an Adaptive Server (for example, a script that was created on a server that originally was not case-sensitive and now that Adaptive Server's sort order has been changed to case-sensitive).
A reserved word has been used in a query (for example select user = suser_name() raises Error 102 because “user” is a reserved word).
You have used a variable instead of a specific period of time following a waitfor delay statement. Variables are not supported in this case. For example, the following would raise Error 102:
1> declare @t char(9) 2> select @t = "00:00:01" 3> waitfor delay @t
You have used a variable for a database name and your query contains a parser error; Error 102 is raised because the batch is never executed. Steps for executing a query are:
Read the batch.
Parse the batch.
Optimize the batch.
Execute the batch.
Any step that fails ends the processing of the query.
Check the spelling and syntax of the command specified in the error message. If it is wrong, correct it in your Transact-SQL statement and run it again.
You can invoke an editor such as vi from isql to edit a SQL statement or statements. However, for the statements to execute, you have to enter the command termination string (usually “go”) after you return to isql. If you include the command termination string in the editor, then save the file and return to isql, the statement will not execute. If you enter the command termination string again after returning to isql, you get the following error (“vi” is the editor in this example; you may be using a different editor):
1> vi
1> select * from sysmessages where error = 102 2> go 3> go
Msg 102, Level 15, State 1: Server 'REL1002_NAME', Line 2: Incorrect syntax near 'go'.
If you are not sure that your query contains a reserved word, use the following query to see a complete list of reserved words:
1> select name from spt_values where type = "W" 2> go
Refer to the documentation for the utility you are using for correct syntax information. Some examples are:
ASE Reference Manual
Transact-SQL User's Guide
ASE utility programs manual
All versions
15
The column prefix '%.*s' does not match with a table name or alias name used in the query. Either the table is not specified in the FROM clause or it has a correlation name which must be used instead.
Tables are specified in the FROM clause of a query. When Adaptive Server parses a query prior to execution, the name by which it knows the table is in the from clause: the table name if given alone, or a correlation name (alias) if one was specified. For example, in the query:
1> select c.cityname from cities c 2> go
the table is known as c for purposes of the query. Names specified in other clauses refer back to this name to determine what table is intended.
Error 107 can be raised:
If a column prefix intended as a table name does not match any table name specified in the from clause.
If a query does not use correlation names consistently. In Adaptive Server, queries that include correlation names must conform to ANSI requirements. Statements that specify correlation names but do not use them consistently return Error 107.
These restrictions apply to views as well as real database tables.
Check your query for these errors and take corrective action:
Check for a typing error like the following:
1> select * from titles 2> where title.code = 205 3> go
Msg 107, Level 15, State 1: Server 'mfg', Line 2: The column prefix 'title' does not match with a table name or alias name used
The column name in the where clause should be titles.code. Likewise this statement is incorrect:
1> select t2.title_id from titles t1
The correct statement is:
1> select t1.title_id from titles t1
Ensure that correlation names are used correctly. For example, this statement is incorrect:
1> select title_id 2> from titles t 3> where titles.type = "french_cook"
The where clause can not use titles, because the from clause defines a correlation name for the table. The correct query is:
1> select title_id 2> from titles t 3> where t.type = "french_cook"
Note the special case where a query that returns Error 107 may report no error when the same type of correlation is used in a subquery. For example:
1> select * from mytable 2> where columnA = 3> (select min(columnB) from mytable m 4> where mytable.columnC = 10)
This query is a correlated subquery, and mytable.columnC refers to the outer table mytable. This query works because the same table is referred to in the inner and outer queries. In general, however, correlated subqueries can also generate Error 107 when correlation names are used incorrectly.
All versions
15
’%.*s’ is not a recognized %S_MSG.
Error 195 is raised when a query contains illegal syntax; more specifically, it is raised when the Adaptive Server parser expects a specific syntaxt (such as a particular command, keyword or punctuation mark) but instead encounters some other syntax or encounters missing text.
Error 195 is raised with the following states:
State |
Meaning |
|---|---|
1 |
Invalid create procedure option. |
2 |
Invalid timestamp keyword on writetext. |
3 |
Invalid log keyword on writetext. |
4 |
Invalid shutdown option, invalid trace keyword on kill, or invalid option on set lock. |
5 |
Invalid set option; covers miscellaneous options that are set to "on" or "off" |
6 |
Invalid option on set offset. |
7 |
All other invalid set options |
8 |
Invalid option on set statistic. |
15 |
Invalid quiesce database begin option |
16 |
Invalid quiesce database end option |
The following common query errors may raise the 195 message:
using incorrect built-in function names (pre-12.5 only; in ASE 12.5 and later, a function that is not a built-in will be treated as an SQLJ function and will raise error 14216 if it is not found.)
using function names (applies to pre-12.5 only) or using keywords that are not recognized by T-SQL.
using an invalid combination of punctuation marks, such as unpaired quotes.
Check the query syntax; the state of the error can be helpful in locating the source of the problem in a complex query.
Check the semantics to make sure that the keywords or options used in the query are valid where they are used in the query.
If Running xp_cmdshell
If the 195 error was raised when you attempted to run xp_cmdshell, check for invalid syntax and check the parameters that were supplied to the procedure. Combinations of single and double quotes can make it impossible for the command to be parsed; replace each double quote (") with two single quotes (’’) and retry.
If Using CIS
If the 195 error was raised when you queried an object in a remote server using Component Integration Services (CIS): your query may be using T-SQL syntax which is not understood by the (non-Sybase) remote server. To correct this, use the sp_passthru stored procedure, which allows you to pass a SQL statement using syntax native to the remote server.
For example:
sp_passthru ORACLE, "select date from shiptable", @errcode output, @errmsg output, @rowcount output, @shipdate output
Refer to the Reference Manual for more information about sp_passthru.
All versions
