I am trying to write an MS SQL statement to fetch a row.
SELECT otherfields, phantom_col FROM mytable WHERE id=5
The above SQL fails with error:
Msg 207 Level 16 Stage 1, Line XX
invalid column name 'phantom_col'.
I loaded SQL Management Studio 2008 R2 and connected to the said database and table and did a "select top 1000 rows" to get the auto generated SQL. It shows:
SELECT TOP 1000 [otherfields], [phantom_col] FROM [mydatabase].[dbo].[mytable]
I then deleted the part that reads [mydatabase] and immediately SQL Management Studio tells me [phantom_col] is invalid.
What special kind of column is that phantom_col? Strictly speaking, if I omit the lengthy [].[] notation, is my SQL syntax still correct?
EDIT: I looked finally looked closely enough and realised there is an error message. edited as above.
Your syntax is correct.
The error, because you haven't connect to the myDatabse
you can use this too
USE mydatabase
GO
SELECT TOP 1000 phantom_col
FROM myTable
When a SQL Server login connects to SQL Server, the login is
automatically connected to its default database and acquires the
security context of a database user. If no database user has been
created for the SQL Server login, the login connects as guest. If the
database user does not have CONNECT permission on the database, the
USE statement will fail. If no default database has been assigned to
the login, its default database will be set to master.
the quote is taken from here
Related
I'm currently working with SQL Server 2008 R2, and I have only READ access to a few tables that house production data.
I'm finding that in many cases, it would be extremely nice if I could run something like the following, and get the total record count back that was affected :
USE DB
GO
BEGIN TRANSACTION
UPDATE Person
SET pType = 'retailer'
WHERE pTrackId = 20
AND pWebId LIKE 'rtlr%';
ROLLBACK TRANSACTION
However, seeing as I don't have the UPDATE permission, I cannot successfully run this script without getting :
Msg 229, Level 14, State 5, Line 5
The UPDATE permission was denied on the object 'Person', database 'DB', schema 'dbo'.
My questions :
Is there any way that my account in SQL Server can be configured so that if I want to run an UPDATE script, it would automatically be wrapped in a transaction with an rollback (so no data is actually affected)
I know I could make a copy of that data and run my script against a local SSMS instance, but I'm wondering if there is a permission-based way of accomplishing this.
I don't think there is a way to bypass SQL Server permissions. And I don't think it's a good idea to develop on production database anyway. It would be much better to have development version of the database you work with.
If the number of affected rows is all you need then you can run select instead of update.
For example:
select count(*)
from Person
where pTrackId = 20
AND pWebId LIKE 'rtlr%';
If you are only after the amount of rows that would be affected with this update, that would be same amount of rows that currently comply to the WHERE clause.
So you can just run a SELECT statement as such:
SELECT COUNT(pType)
FROM Person WHERE pTrackId = 20
AND pWebId LIKE 'rtlr%';
And you'd get the resulting potential rows affected.
1.First Login as admin in sqlserver
2.Goto login->your name->Check the roles.
3.IF u have write access,then you can accomplish the above task.
4.If not make sure you grant access to write.
If it's strictly necessary to try the update, you could write a stored procedure, accepting dynamic SQL as a string (Your UPDATE query) and wrapping the dynamic SQL in a transaction context which is then rolled back. Your account could then be granted access to that stored procedure.
Personally, I think that's a terrible idea, and incredibly unsafe - some queries break out of such transaction contexts (e.g. ALTER TABLE). You may be able to block those somehow, but it would still be a security/auditing problem.
I recommend writing a query to count the relevant rows:
SELECT COUNT(*)
FROM --tables
WHERE --your where clause
-- any other clauses here e.g. GROUP BY, HAVING ...
I've got a stored procedure which takes two parameters. I'm trying to use OpenQuery in SQL Server to join on the result set of my stored procedure dbo.TwoDrugs. The SQL Server is only a local machine with no one else having access. I'm trying to do
select *
from OpenQuery (AHCTW208D02,'exec [i 3 sci study].dbo.TwoDrugs ''X'',''Y''')
and I get the error
Msg 7357, Level 16, State 2, Line 1
Cannot process the object "exec [i 3 sci study].dbo.TwoDrugs 'X','Y'". The OLE DB provider "SQLNCLI10" for linked server "AHCTW208D02" indicates that either the object has no columns or the current user does not have permissions on that object.
I can't think of a reason why I wouldn't have permission (since I created the stored procedure), and I configured the server for data access.
When I run the stored procedure it does in fact return a result set. Any ideas on what might be the problem with this?
OPENQUERY cannot be used to execute extended stored procedures on a linked server. However, an extended stored procedure can be executed on a linked server by using a four-part name. For example:
exec AHCTW208D02.[i 3 sci study].dbo.TwoDrugs 'X','Y';
please read Remaks
Reference: http://msdn.microsoft.com/en-us/library/ms188427.aspx
Is it possible to modify the table creation date of a table? The date which we see on right clicking a table > properties > Created date or in sys.tables.create_date.
Even though the tables were created months ago, I want it to look like they were created today.
No more than you can change your birthday, and why would you want to ?
You could just
select * into #tmp from [tablename]
drop table [tablename]
select * into [tablename] from #tmp
That would rebuild the table and preserve the structure (to a point). You could script a new table , copy data then drop and rename. As above.
In SQL Server 2000, you could do this by hacking into the system tables with the sp_configure option 'allow updates' set to 1.
This is not possible in SQL Server 2005 and up. From Books Online:
This option is still present in the sp_configure stored procedure,
although its functionality is unavailable in Microsoft SQL Server 2005
(the setting has no effect). In SQL Server 2005, direct updates to the
system tables are not supported.
In 2005 I believe you could "game the system" by using a dedicated administrator connection, but I think that was fixed shortly after RTM (or it needs a trace flag or some other undocumented setting to work). Even using DAC and with the sp_configure option set to 1, trying this on both SQL Server 2005 SP4 and SQL Server 2008 R2 SP1 yields:
Msg 259, Level 16, State 1
Ad hoc updates to system catalogs are not allowed.
Who are you trying to fool, and why?
EDIT
Now that we have more information on the why, you could create a virtual machine that is not attached to any domain, set the clock back to whatever date you want, create a database, create your objects, back up the database, copy it to the host, and restore it. The create_date for those objects should still reflect the earlier date, though the database itself might not (I haven't tested this).
You can do this by shifting the clock back on your own system, but I don't know if I'd want to mess with my clock this way after SQL Server has been installed and has been creating objects in what will become "the future" for a short period of time. VM definitely seems safer to me.
I would like to update rows over linked server. I created linked server on my local SQL-Server with this instruction.
I can update rows over Query Analyzer with below code. No error returned and rows update on Linked Server successfully.
UPDATE [LinkedServer].[Database].[dbo].[Table]
SET A = 'A', B = 'B'
WHERE id = 1
But when I created a update trigger to my table on my local sql server like below,
ALTER TRIGGER [TriggerLocalServerTable]
ON dbo.[LocalServerTable]
FOR UPDATE
AS
DECLARE #A varchar(4)
DECLARE #B varchar(4)
DECLARE #id int
BEGIN
SELECT
#A = A,
#B = B,
#id = id
FROM inserted
UPDATE [LinkedServer].[Database].[dbo].[Table]
SET A = #A, B = #B
WHERE id = #id
END
When trigger performed, returns this error like below,
OLE DB provider "SQLNCLI" for linked
server "LinkedServer" returned message
"The partner transaction manager has
disabled its support for
remote/network transactions.". Msg
7391, Level 16, State 2, Procedure
TriggerLocalServerTable, Line 45
The operation could not be performed
because OLE DB provider "SQLNCLI" for
linked server "LinkedServer" was unable
to begin a distributed transaction.
I applied this instruction to local server for solving issue, anything changed.
More details;
if defined my linked server with its
remote ip address.
My local server and Linked Server
not in same domain.
Linked Server Security setting is "Be
made using this security context"
Local server version is Windows
Server 2003 SP2, SQL-Server version is 2005
standart.
Linked server OS version is 2008 and
SQL-Server version 2008 (64 bit).
I couldn't access remote server
with RDP. i can access just from sql
port (1433).
i set linked server "RPC" and "RPC
Out" to "True" from "Security Option".
Do you have any idea to solve this issue.
Thank you very much already now.
Edit:
I solved this issue. Firstly i created a trigger for update on [TriggerLocalServerTable]. This trigger's job is inserting new update fields to a local table. This new table using for updated temp datas. Then i created a job that runs every hour for update fileds on LinkedServer. This job gets data from temp table then update to LinkedServer table's fields.
Regards, Kerberos.
Do you have a Distributed Transaction Coordinator installed on Windows Server? If your update is inside a transaction, it won't work without it.
See
link text
The problem dont lies with SQL Server it is with ODBC Driver.
Go to Start > Settings > Control Panel > Administrative Tools > Data Sources
Open System DSN Tab
Select the driver you have used for Linked Server and click configure
Select Advanced > Flags3 and Uncheck Disable transaction check box
Problem Solved :)
We have 2 databases, say DB1 and DB2.
DB1 contains all the stored procedures which access also data in DB2.
DB1 uses synonyms to access the tables in DB2.
(Using synonyms is a requirement in our situation)
This works perfectly fine in all situations with SQL Server 2005 Developer Edition.
However in the Express Edition, we get an exception when we do the following:
1 Restart SQL Server
2 Execute the following code within DB1:
set transaction isolation level snapshot
begin transaction
declare #sQuery varchar(max)
set #sQuery = 'Select * from synToSomeTableInDB2'
exec (#sQuery)
commit transaction
This will result in the following error:
Snapshot isolation transaction failed in database '...' because the database was not recovered when the current transaction was started. Retry the transaction after the database has recovered.
The same select query passes fine when used without the EXEC or when run on the Developer Edition.
Restarting the server in step 1 is important as once a connection was made to DB2, the code runs also fine on SQL Server Express Edition.
Does anyone have an idea what this is? We need to be able to use EXEC for some dynamic queries.
We've already checked MSDN, searched Google, ...
Any help is greatly appreciated.
--- Edit: March 10 09
As discussed with Ed Harper below, I've filed a bug report for this.
See https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=422150
As found out via Microsoft Connect, the problem is that by default on SQL Server Express Edition the AUTO_CLOSE option is set on true.
Changing this option to false fixes the problem.
The error message suggests that the query fails because SQL server is still recovering the database following the service restart when you execute your query.
Does the error always occur on the first attempt to run this code, regardless of the time elapsed since the service was restarted?
Can you confirm from the SQL Server log that the database is recovering correctly after the restart?