I'm getting the following error(s)
Msg 117, Level 15, State 1, Procedure lp_..._data, Line 153
The object name 'abcDBProd.Intermediate.dbo.upld_data' contains more than the maximum number of prefixes. The maximum is 2.
Msg 117, Level 15, State 1, Procedure lp_..._Tables, Line 520
The object name 'ABCDBPROD.Intermediate.dbo.UPLD_data' contains more than the maximum number of prefixes. The maximum is 2.
If I understand correctly the purpose/meaning of the error that I can't have more then 2 prefixes prior to the table name. In the first statement i'm using the name of the Server itself and in the second case the LinkedServer name. The confusion I've got is that i have many tables on this server/databse and they are all connected the same and none of them are causing this error. but this one is.
What do I do? Is it a permission issue or security issue? I'm not sure where to look.
Does it matter if the command calling the table, truncates, inserts or updates the data? Are there restrictions like I can't truncate but I can insert? Why does it work in some cases but not in others?
Linked tables are not allowed in some contexts, such as DROP TABLE and INSERT INTO. If you use a name that includes the server name, then you will get this error.
For instance, this is not allowed:
drop table abcDBProd.Intermediate.dbo.upld_data;
You may be able to work around this with openquery().
Related
I have a problem with error handling. I'm using Try/Catch-blocks and this works very good for me. But in some cases there's not only one error raised but more. Then I'm only getting the last error message.
Let me give an example :
When executing this block :
alter table [dbo].[table]
add constraint [somefk]
foreign key ([somecol]) references [dbo].[parenttab] ([someid])
it raises 2 errors:
Msg 1778, Level 16, State 0, Line 7
Column 'dbo.parenttab.someid' is not the same data type as referencing column 'table.somecol' in foreign key 'somefk'.
Msg 1750, Level 16, State 1, Line 7
Could not create constraint or index. See previous errors.
So far, so good. But in case I put the statement in a Try/Catch block, the first message (1778) "is eaten" by someone.
In the end, I'm getting only the second message with the non-significant text :(
So, what I'm missing is a kind of an error collection, well-known from programming languages or frameworks. Or is it just a "Missing feature" in SQL Server...? How can I get the proceeding error message?
Thanks a lot in advance and best regards!
fksof
I want to copy my table into AMAPHLINK server, but it keeps giving me an error.
select *
into AMAPHLINK.Payroll.dbo.[EmpResignTb]
from Payroll.dbo.EmpResignTb
Error:
The object name 'AMAPHLINK.Payroll.dbo.EmpResignTb' contains more than
the maximum number of prefixes. The maximum is 2
You are getting an error because you are not using a valid name.
The valid syntax is server_name.database_name.schema_name.object_name as referenced on the MSDN article for INSERT.
Remove the incorrect schema and try again.
Solution:
Use square brackets "[]" around the name and remote database server
select *
into [AMAPHLINK].[Payroll].[dbo].[EmpResignTb]
from [Payroll].[dbo].[EmpResignTb]
It appears this can't be done over linked servers.
You could create the table first then do an INSERT INTO.
The same question was asked here:
error when insert into linked server
Whenever I make a syntax error in a SQL Server query, I get an error message which I find pretty hard to interpret. For example the error that I have right now is
Msg 102, Level 15, State 1, Procedure myQuery, Line 3 [Batch Start Line 57]
Incorrect syntax near '!'.
I used table!column instead of table.column. I fixed my problem because I understood this bit:
Incorrect syntax near '!'
However, I do not understand how to interpret this message
Msg 102, Level 15, State 1, Procedure myQuery, Line 3 [Batch Start Line 57]
Do people usually just ignore that part? I have been getting along just fine without paying much attention to it. But being able to understand the error message might help be locate exactly where the error is.
Edit:
I don't understand what Msg, Level, State, Batch and Start Line means
Edit2:
Besides the accepted answer this link also helped me clear up my misunderstanding of what line number means. I always thought that line number meant the line in the SQL query where the error is which confused me. Turns out the line number is the line in the query window. To enable line number in query editor window go to :
Tools > Options > Text Editor > Transact-SQL > General >Line Numbers
Press OK
From Understanding Database Engine Errors:
Errors raised by the Microsoft SQL Server Database Engine have the (following) attributes:
Error number
Each error message has a unique error number.
Error message string
The error message contains diagnostic information about the cause of the error. Many
error messages have substitution variables in which information, such as the name of
the object generating the error, is inserted.
Severity
The severity indicates how serious the error is. Errors that have a low severity, such
as 1 or 2, are information messages or low-level warnings. Errors that have a high
severity indicate problems that should be addressed as soon as possible.
State
Some error messages can be raised at multiple points in the code for the Database
Engine. For example, an 1105 error can be raised for several different conditions.
Each specific condition that raises an error assigns a unique state code.
When you are viewing databases that contain information about known issues, such as
the Microsoft Knowledge Base, you can use the state number to determine whether the
recorded issue is the same as the error you have encountered. [...]
Procedure name
Is the name of the stored procedure or trigger in which the error has occurred.
Line number
Indicates which statement in a batch, stored procedure, trigger, or function generated
the error.
Specifically, [Batch Start Line 57] means that you are running a script with multiple batches - (if it's in SSMS the batches are separated by the GO keyword) - so the error is in the 3rd line of the batch that starts in line 57 of the script.
Here's a break down of the error message you've posted to it's parts:
ErrorNumber
Msg 102,
Severity
Level 15,
State
State 1,
Procedure
Procedure myQuery,
Line number
Line 3 [Batch Start Line 57]
Error message string
Incorrect syntax near '!'.
Unfortunately, this did not work for me. I use the latest version of SSMS or sql server management studio. I have a SQL script (in query editor) which has about 100 lines of code. This is error I got in the query:
Msg 245, Level 16, State 1, Line 2
Conversion failed when converting the nvarchar value 'abcd' to data type int.
The error message is either incorrect or simply misleading. The actual error on line number 70 in the query editor ! When, I click on the error message, it takes me to line 2 which is just a simple select top 1. Google searches revealed that the error had something to do with String concatenation, but there was no concatenation in my sql code.
Luckily, I remembered that I had seen this kind of error before when I forgot to enclose a number (in varchar column) in single quotes. So, it looks like SSMS is useless when it comes to debugging errors.
Might get some negative points here but feel the need to post an problem (And self-defined solution) that I could not match to anything on the interweb...
I have a very simple bit of code that returns the queries that my company's SSRS RDL datasets uses to obtain data.
It works nicely when returning all data, but the moment I add a where clause to only return records with specific text within the data set like the parameter I get an error:
Msg 8152, Level 16, State 10 ...
String or binary data would be truncated
The parameter is defined exactly the same as the column I am searching in is (NVARCHAR(MAX)).
I know what that error means ("The error means that you're trying to put a value into a table that is larger than what the column can hold. I.e. you're to insert a varchar(100) into a column that's been defined as varchar(80).") but what stumped me was that the flippen thing only errors out when run the query with the where clause.
I managed to narrow the culprit record down to one having 12351 characters (Using LEN).
The solution that I found was to change the LIKE to an =. Not 100% ideal because I would like the flexibility to search for any text within the column, but I can live with it.
If you are using LIKE operator in following manner:
WHERE myColumn LIKE '%some text%`
which I suspect you do from your description:
to search for any text within the column
Then, you can replace it with WHERE CHARINDEX('some text', myColumn) > 0 and see if it will work.
Shouldn't one of these statements work and one fail?
Intuition says Statement 2 should fail because there is a comma after int and no second column listed.
Yet both work and the trailing comma "," after the last column data type makes no difference.
-- Statement 1
CREATE TABLE dbo.MyTable1( col1 int);
-- Statement 2
CREATE TABLE dbo.MyTable2( col1 int,);
However (and this is expected): two commas ",," after the last field do cause a failure:
-- Statement 3
CREATE TABLE dbo.MyTable3( col1 int,,);
Msg 102, Level 15, State 1, Line 1
Incorrect syntax near ','.
Testing shows that its not just any character after the last field that is allowed through. For example, this fails:
-- Statement 3
CREATE TABLE dbo.MyTable3( col1 int ~);
Msg 102, Level 15, State 1, Line 1
Incorrect syntax near '~'.
Maybe SQL Server is "saving a seat at the table" for something? The Primary Key perhaps? I really don't know.
I am using Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64).
See http://connect.microsoft.com/SQLServer/feedback/details/273348/trailing-comma-allowed-in-create-table:
Description
When executing the CREATE TABLE command, a trailing comma following
the last column is allowed. Based on the grammar in BOL and comma
usage in lists in other T-SQL statements, this behavior is
inconsistent. This is a very minor issue and does not appear to cause
any adverse side-effects. It just appears that the parser may be a bit
off.
Microsoft views this as a bug, but a minor one.
This was resolved some time ago as "won't fix" but we didn't explain why. Simply, this seems pretty harmless, and not worth fixing in a service pack. We may consider fixing this in a future release.
It should be flagged as a syntax error, but there is a bug in SQL Server that doesn't treat the trailing comma as a syntax error.
Source: Microsoft Support (The affected versions in the list - 6, 6.5, and 2000 - are old, but I guess it's still around because it just worked for me in 2008.)
Almost all languages which permit comma-separated list items permit a comma after the last list item. This is done to make editing the program or file, and especially inserting new list items, easier. You don't have to worry about adding a comma after the current last list item, or removing a comma if you delete the old last list item.