I have a utility database (customers) on my db server where I store all of the routines used to modify data on the other databases. We recently found out that using synonyms will greatly benefit us.
use Customers
IF EXISTS (SELECT * FROM employees.sys.synonyms WHERE name = 'tblPerson2') begin
drop synonym [dbo].tblPerson2
end
This doesn't work because I am using the Customers database but need to drop the synonym from my employees database.
SQL Server 2008 doesn't support this syntax -
drop synonym [employees].[dbo].tblPerson2
Anyone have any ideas on how to modify synonyms accross databases. My solution involves having to add an identical stored procedure to every database, which seems prone to error.
EXEC('USE employees;
DROP SYNONYM [dbo].tblPerson2;')
Related
I'm writing some dynamic SQL (I'm fairly new to it) and am trying to automate the altering of multiple tables which may exist on different instances of SQL Server 2008. My servers are linked and I know which server each of the tables exists on, however when I try to run the query below, I get "Cannot find object...because it does not exist or you do not have persmissions"
Query:
Alter Table [Server10].[Database2].[dbo].[documents] Add NewField int
If I connect to the server in SSMS and drop the server name (Server10) it works.
Any suggests on how to create this query. Thanks
I believe that alter table on a linked server is not supported. You could do something like this:
EXECUTE [Server10].[Database2].[dbo].sp_executesql N'ALTER TABLE [documents] Add NewField int'
I recently upsized my MS-Access database to SQL Server and in the process successfully exported a bunch of tables.
However, now the imported tables are prefixed with MSH-CHAMBERS\mfanimpela which I assume is my username and this is the schema (or owner property).
While I have seen posts on changing EACH table schema to the desired 'dbo', I want a statement that can help me change ALL of my tables (since these are so many).
Please help - chagbert.
Use the sp_MSForEachTable procedure like this:
EXEC **sp_MSForEachTable** 'ALTER SCHEMA dbo TRANSFER ?'
-- in the above example dbo is the targeted schema where you want to place your tables
Google sp_MSForEachTable and use it to call sp_rename
You might need to do additional checks before you rename the table to avoid mistakes.
I need the "create table... " statement for a particular table and stored procedure to recreate them in another database. Forget the backup and restore. I have to do it in vb6. Its the same thing you get when you copy the Table And paste it in query analyzer. Its sql server 2000
Edit: Now I Know it can be asked as 'How To Script Entire Database Through VB6'.
Take a look at this StackOverlow post which talks about the same. Although it is not VB6-specific, you should be able to apply this solution without a problem.
Essentially you create a stored procedure that will generate the CREATE TABLE statement for the given table. The stored procedure will examine the sysobjects table to build the SQL.
Your VB6 application can run the stored procedure on server 'A' fetching the CREATE TABLE SQL. Then connect to server 'B' and run that SQL to create the table on the other server.
I struggled for a while with a bug, and then found out the reason for it in a database stored procedure code, which contained the old name of a database in a table name, whereas the current database name was already different. So, I'd like to ask:
Is there a situation in which using a database name as a part of a full table name (database name + schema name + table name) can be justified (provided we don't touch tables in other databases) or is it always a bad practice? How to correctly use a database name in sql scripts to keep code neutral to a specific database?
Code just for an illustration:
CREATE PROCEDURE [dbo].[MyProc]
AS
BEGIN
DELETE FROM [MyDatabase].[dbo].[MyTable]
END
No, you shouldn't use database names in a stored procedure unless you need to address two databases.
It causes exactly the kinds of bugs you're seeing. When the database name changes, all your SP code breaks, or continues working, but on the old database.
It does make sense if you are sending a SQL query to the database, but only if the application dynamically picks the database name to insert into the query.
My suggestion is that you do a full export of your database schema, and search for database names that are hardcoded and remove them.
It really depends on how your scripts are implemented.
Even if you don't refer to a table as
[MyDatabase].[dbo].[MyTable]
you will still need to refer to the database by:
USE [MyDatabase]
earlier in the script.
It is possible to mix trusted database tables in a single query. When someone do this,it is justified and mandatory to include database on table 'path'.
I don't found a reason out of this scenario if stored procedure and table is on the same database.
You can search all database name occurencies through database catalog in order to fix your development. For SQL Server 2005:
SELECT Name
FROM sys.procedures
WHERE OBJECT_DEFINITION(OBJECT_ID) LIKE '%databasename%'
GO
For SQL Server 2000:
SELECT DISTINCT so.name
FROM syscomments sc
INNER JOIN sysobjects so ON sc.id=so.id
WHERE sc.TEXT LIKE '%databasename%'
GO
SQL Server: is it possible to get procedure or table creation and last alter date?
If it is then how do to it?
SQL Server 2005
Sure:
SELECT name, create_date, modify_date
FROM sys.tables
SELECT name, create_date, modify_date
FROM sys.procedures
The system catalog views in the sys schema are present in SQL Server 2005 and up, and provide a wealth of (metadata) information about the database objects.
Check out the MSDN / SQL Server Books Online docs on Querying the SQL Server System Catalog for a lot more details and information.
If you want to take things to the next level and implement a custom schema change tracking solution you can do so by using DDL Triggers.
Take a look at Using DDL Triggers in SQL Server 2005
It is common to use such techniques in order to record what has changed and to even block/rollback changes of an undesirable nature.