Can someone point me to the relevant BOL info for this (odd to me) behavior?
I had to join the prod & staging copies of the same table (same db name, diff servers), for a quick query. So I simply needed a fully-qualified join.
This one errors:
SELECT top 10 *
FROM [172.26.196.105\Staging].[DbName].[dbo].[TableName]
This one works:
SELECT top 10 *
FROM [USCASQL01\STAGING].[DbName].[dbo].[TableName]
Edit: clarification ... obviously not a join, these selects were simply me assembling the fully qualified name of my staging db/table. This is not a linked server, but the one I'm connected to.
These, of course, refer to the same instance. I used the IP address\InstanceName since that is what displays in my Object Explorer, it returned an error - "Could not find server 'IP address\InstanceName' in sys.servers." True enough, sys.servers stores the computerName\InstanceName, which works.
Why would one work and not the other? IOW, Why can't it resolve the IP/Instance name in TSQL when it resolves it just fine in the Object Explorer? BTW, we frequently are storing IP's in sys.servers, this one just happened not to be.
Also, I recall from SQL Server7 (way back in the day), a utility that would allow you to create friendly-name aliases for ip's. Can't find it now, does it still exist?
TIA
This is because the first part of a four part qualified name is a reference to a linked server by name, not by an IP or network name. So, if you don't have the linked server set up, then you get the error you encountered.
For adding linked servers, you want to be looking at sp_addlinkedserver.
This is the BOL Page that describes how the four part names work.
Related
I'm wanting to be able to input any given report server url and display a list of reports available on that server.
I found this question, and it's useful if I compile the project with a reference to a specific sql server (How do I get a list of the reports available on a reporting services instance). But (unless I'm just completely missing something which is possible) it doesn't show me how to do what I've stated above.
You could query the ReportServer database of your reporting server.
SELECT *
FROM dbo.Catalog
WHERE Type = 2
Should give you a list of all of the reports.
You can go to Web Service URL (note: not Report Manager URL). So if your main managing URL is http://server/Reports and Web Service URL is http://server/ReportServer - open the second one. It will give you raw listing of available items.
Note that this will include reports, datasources, folders etc.
Same as answer above,
with a use clause added at top
(in case this helps anyone ..) :
Use ReportServer;
SELECT *
FROM dbo.Catalog
WHERE Type = 2
Order by Name
I noted that select * above contains a field called Content which might be an issue for an export of result to excel .. So I tried a lesser list of columns :
Use ReportServer;
SELECT
ItemID,
Path,
Name,
ParentID,
Type,
Description,
Hidden,
CreatedByID,
CreationDate,
ModifiedByID,
ModifiedDate,
Parameter
FROM dbo.Catalog
WHERE Type = 2
Order by Name
The first answer above didn't seem to work for me ..
i.e. http://server/ReportServer
(replacing server with my reporting server name ..)
I get message "The webpage cannot be found" ..
Maybe this answer is version or security settings specific ?
I've hit a bit of an impasse. I have a query that is generated by some C# code. The query works fine in Microsoft SQL Server Management Studio when run against the same database.
However when my code tries to run the same query I get the same error about an invalid column and an exception is thrown. All queries that reference this column are failing.
The column in question was recently added to the database. It is a date column called Incident_Begin_Time_ts .
An example that fails is:
select * from PerfDiag
where Incident_Begin_Time_ts > '2010-01-01 00:00:00';
Other queries like Select MAX(Incident_Being_Time_ts); also fail when run in code because it thinks the column is missing.
Any ideas?
Just press Ctrl + Shift + R and see...
In SQL Server Management Studio, Ctrl+Shift+R refreshes the local cache.
I suspect that you have two tables with the same name. One is owned by the schema 'dbo' (dbo.PerfDiag), and the other is owned by the default schema of the account used to connect to SQL Server (something like userid.PerfDiag).
When you have an unqualified reference to a schema object (such as a table) — one not qualified by schema name — the object reference must be resolved. Name resolution occurs by searching in the following sequence for an object of the appropriate type (table) with the specified name. The name resolves to the first match:
Under the default schema of the user.
Under the schema 'dbo'.
The unqualified reference is bound to the first match in the above sequence.
As a general recommended practice, one should always qualify references to schema objects, for performance reasons:
An unqualified reference may invalidate a cached execution plan for the stored procedure or query, since the schema to which the reference was bound may change depending on the credentials executing the stored procedure or query. This results in recompilation of the query/stored procedure, a performance hit. Recompilations cause compile locks to be taken out, blocking others from accessing the needed resource(s).
Name resolution slows down query execution as two probes must be made to resolve to the likely version of the object (that owned by 'dbo'). This is the usual case. The only time a single probe will resolve the name is if the current user owns an object of the specified name and type.
[Edited to further note]
The other possibilities are (in no particular order):
You aren't connected to the database you think you are.
You aren't connected to the SQL Server instance you think you are.
Double check your connect strings and ensure that they explicitly specify the SQL Server instance name and the database name.
In my case I restart Microsoft SQL Sever Management Studio and this works well for me.
If you are running this inside a transaction and a SQL statement before this drops/alters the table you can also get this message.
I eventually shut-down and restarted Microsoft SQL Server Management Studio; and that fixed it for me. But at other times, just starting a new query window was enough.
If you are using variables with the same name as your column, it could be that you forgot the '#' variable marker. In an INSERT statement it will be detected as a column.
Just had the exact same problem. I renamed some aliased columns in a temporary table which is further used by another part of the same code. For some reason, this was not captured by SQL Server Management Studio and it complained about invalid column names.
What I simply did is create a new query, copy paste the SQL code from the old query to this new query and run it again. This seemed to refresh the environment correctly.
In my case I was trying to get the value from wrong ResultSet when querying multiple SQL statements.
In my case it seems the problem was a weird caching problem. The solutions above didn't work.
If your code was working fine and you added a column to one of your tables and it gives the 'invalid column name' error, and the solutions above doesn't work, try this: First run only the section of code for creating that modified table and then run the whole code.
Including this answer because this was the top result for "invalid column name sql" on google and I didn't see this answer here. In my case, I was getting Invalid Column Name, Id1 because I had used the wrong id in my .HasForeignKey statement in my Entity Framework C# code. Once I changed it to match the .HasOne() object's id, the error was gone.
I've gotten this error when running a scalar function using a table value, but the Select statement in my scalar function RETURN clause was missing the "FROM table" portion. :facepalms:
Also happens when you forget to change the ConnectionString and ask a table that has no idea about the changes you're making locally.
I had this problem with a View, but the exact same SQL code worked perfectly as a query. In fact SSMS actually threw up a couple of other problems with the View, that it did not have with the query. I tried refreshing, closing the connection to the server and going back in, and renaming columns - nothing worked. Instead I created the query as a stored procedure, and connected Excel to that rather than the View, and this solved the problem.
I have a production server and I standardized the names of all the DBs on the server to
projectName.whatever
The problem is I have one database named
projectName_logging
I want to rename it to
projectName.Logging
(OCD a bit?)
The problem is there are connection strings that all say projectName_logging. Is there a way to say if a connection is projectName_logging to automatically redirect it to a catalog now named projectName.logging ?
As requested by the OP, I'm making my comment an answer.
Sounds like what you really want is a synonym for a database name, which doesn't exist, but you can vote for the feature here.
This may be a dumb question. But I just received permissions to read/write to this DB. I see the tables of the DB, except for one. I can select from it, But I cannot see it in the Object Explorer. I restarted my computer, refreshed the object explorer and everything. Is there a restriction on viewing this table?
I"m so sorry I had to check the connection of the query. I was looking at two different versions of the same DATABASE. gosh. Should I take this question down?
The query
SELECT type, type_desc FROM sys.objects WHERE name = 'my_table_name'
should tell you what type of object your table really is.
Could it be a synonym, or a view? Check under the synonyms node and the views node. Also check the schema... if you are just saying SELECT * FROM table, try with SELECT * FROM dbo.table. It may be under a different schema.
You need to use the schema name in your create table query(eg. dbo.table name). By default it is getting created under your local server and hence it is available for you when you use the select query but once you check on server ita is not available.
When all else fails, right click on Tables and click Refresh.
I'm trying to pull user data from 2 tables, one locally and one on a linked server, but I get the wrong results when querying the remote server.
I've cut my query down to
select * from SQL2.USER.dbo.people where persId = 475785
for testing and found that when I run it I get no results even though I know the person exists.
(persId is an integer, db is SQL Server 2000 and dbo.people is a table by the way)
If I copy/ paste the query and run it on the same server as the database then it works.
It only seems to affect certain user ids as running for example
select * from SQL2.USER.dbo.people where persId = 475784
works fine for the user before the one I want.
Strangely I've found that
select * from SQL2.USER.dbo.people where persId like '475785'
also works but
select * from SQL2.USER.dbo.people where persId > 475784
brings back records with persIds starting at 22519 not 475785 as I'd expect.
Hope that made sense to somebody
Any ideas ?
UPDATE:
Due to internal concerns about doing any changes to the live people table, I've temporarily moved my database so they're both on the same server and so the linked server issue doesn't apply. Once the whole lot is migrated to a separate cluster I'll be able to investigate properly. I'll update the update once this happens and I can work my way through all the suggestions. Thanks for your help.
The fact that LIKE operates is not a major clue: LIKE forces integers to string (so you can say WHERE field LIKE '2%' and you will get all records that start with a 2, even when field is of integer type). Your incorrect comparisons would lead me to think your indexes are corrupt, but you say they work when not used via the link... however, the selected index might be different depending on the use? (I seem to recall an instance when I had duplicate indexes and only one was stale, although that was too long ago to recall the exact cause).
Nevertheless, I would try rebuilding your index using the DBCC DBREINDEX (tablenname) command. If it turns out that doing so fixes your query, you may want to rebuild them all: here is a script for rebuilding them all easily.
Is dbo.people a table or a view? I've seen something similar where the underlying table schema had been changed and dropping and recreating the view fixed the problem, although the fact that the query works if run directly on the linked server does indicate something index based..
Is the linked server using the same collation? Depending on the index used, I could see something like this perhaps happening if the servers were not collation compatible, but the linked server was set up with collation compatible (which tells Sql Server it can run the query on the remote server).
I would check the following:
Check your definition on the linked server, and confirm that SQL2 is the
server you expect it to be
Check and compare the execution plans both from the remote and local servers
Try linking by IP address rather than name, to ensure you have the proper machine
Put the code into a stored procedure on the remote machine, and try calling that instead
Sounds like a bug to me - I;ve read of some issues along these lines, btu can't remember specifically what. What version of SQL Server are you running?
select * from SQL2.USER.dbo.people where persId = 475785
for a PersID which fails how does:
SELECT *
FROM OpenQuery(SQL2, 'SELECT * FROM USER.dbo.people WHERE persId = 475785')
behave?