I'm trying to export our production Azure SQL database to local for testing purposes. I've made a copy of the database but get the following error when trying to Export.
One or more unsupported elements were found in the schema used as part of a data package.
Error SQL71501: Error validating element [dss]: Schema: [dss] has an unresolved reference to object [##MS_SyncAccount##].
Error SQL71501: Error validating element [TaskHosting]: Schema: [TaskHosting] has an unresolved reference to object [##MS_SyncAccount##].
I've found this article explaining how to get around this issue:
https://techcommunity.microsoft.com/t5/azure-database-support-blog/exporting-a-database-that-is-was-used-as-sql-data-sync-metadata/ba-p/369062.
My question is, will running the script below (from the article) on the copied database affect only the copy's data sync meta data, or is there a risk that it will affect our production database or server in any way?
Script:
https://raw.githubusercontent.com/vitomaz-msft/DataSyncMetadataCleanup/master/Data%20Sync%20complete%20cleanup.sql
Many thanks
The script provided in the link will only clean up sync database objects, you can check the schema name mentioned in the where condition. If you want to be more sure you can just run the select statements and re-verify the objects against the main database.
As an example, below statement would fetch stored procedures with specific schema name mentioned in the where clause.
select #procedures = isnull( #procedures + #n, '' ) + 'drop procedure [' + schema_name(schema_id) + '].[' + name + ']'
from sys.procedures
where schema_name(schema_id) = 'dss' or schema_name(schema_id) = 'TaskHosting' or schema_name(schema_id) = 'DataSync'
Related
I have a legacy db from an application that is no longer supported. I'm trying to deconstruct a stored procedure to make a modification, but I can't figure out where #tempimport is located. I've searched high and low through the schema, but I'm not finding anything close. This is how it's used:
SET NOCOUNT ON;
DECLARE #saleid UNIQUEIDENTIFIER
SELECT TOP 1 #saleid = [sale_id] FROM #tempimport;
Is this a T-SQL specific thing, or can I actually find the data in this table somewhere?
Tables with the # preceding the name are temporary tables.
You can find them in the tempdb database under System Databases
Tables that are prefixed with a # are temporary tables that are created in the tempdb system database.
try to find code of this table creation in you DB schema
select * from information_schema.routines
where object_definition(object_id(routine_name)) like '%#tempimport%'
try find #tempimport in schemas of neighboring DBs
try find #tempimport in your application sources if exists.
try to profile(SQL Profiler tool) your application and search #tempimport here.
Additional
#tempimport can be created by any connected application. Not only from your DB runnable code
you can research deeper and try to monitoring the moment of #tempimport creation. Example
select left(name, charindex('_',name)-1)
from tempdb..sysobjects
where charindex('_',name) > 0 and
xtype = 'u' and not object_id('tempdb..'+name) is null
and left(name, charindex('_',name)-1) = '#tempimport'
source: Is there a way to get a list of all current temporary tables in SQL Server?
When trying to export a data tier application or dacpac from a database that contains functions that use "for xml" every single function and every single object that depends upon that function fails and I am not able to create the dacpac. The wizard reports those objects as not supported.
Database : SQL Server 2008 R2
The error that the functions fail with:
[dbo].[fn_FunctionName] () Failed Depends on object '[XmlData].[value] (UnresolvedEntity)', which does not exist in this database.
Example query:
declare #XMLColumn xml = '<Example><Node>Test</Node></Example>'
select XmlData.value('.', 'varchar(50)') + ';'
from #XMLColumn.nodes('/Example/Node') T2(XmlData)
for xml path('')
I know it has been a long time but changing your query to the following
declare #XMLColumn xml = '<Example><Node>Test</Node></Example>'
select T2.XmlData.value('.', 'varchar(50)') + ';'
from #XMLColumn.nodes('/Example/Node') T2(XmlData)
for xml path('')
I'm a SQL Server newbie. I've tried foraging around on the web for a while but could not get my question answered. Can anyone please tell me where exactly is a view stored in SQL server 2008 database?
The pedantic answer to your question is... only Microsoft knows exactly where view metadata is physically stored. In the move from SQL 2000 to SQL 2005 (on which 2008 is based) MS got rid of direct access to system tables where views used to be literally stored (dbo.sysviews and dbo.syscomments) and added a layer of abstraction (via the hidden resources database) which means you can only access meta data about views via catalog views. INFORMATION_SCHEMA is an ANSI compliant set of catalog views. While marginally useful for their relative portability between versions, often more information is available from the sql 2008 catalog views - in this case sys.views and sys.sql_modules
Be aware that views can be created with the ENCRYPTION option set which encrypts the sys.comments record(s) that contain the SQL definition of the view. But if not encrypted, then sp_helptext [MyView] will give you a quick look at the definition.
edited as per 1st comment below, to replace "sys.comments" with "sys.sql_modules"
Note: Based on this post
http://improve.dk/archive/2012/08/27/where-does-sql-server-store-the-source-for-stored-procedures.aspx, is very likely that the definition of views are stored (also) in sys.sysobjvalues system table.
The list of all user T-SQL modules (within SQL Server 2008) can be queried using sys.sql_modules system view (link). Here, you can find the definitions of user views (column definition):
SELECT QUOTENAME(s.name)+'.'+QUOTENAME(o.name) AS full_object_name,
m.*
FROM sys.sql_modules m
JOIN sys.objects o ON m.object_id=o.object_id
JOIN sys.schemas s ON o.schema_id=s.schema_id
WHERE o.type='V' -- only view objects
ORDER BY full_object_name
If you run EXEC sp_helptext 'sys.sql_modules' you will get the source code of this system view:
CREATE VIEW sys.sql_modules AS
SELECT object_id = o.id,
definition = object_definition(o.id),
uses_ansi_nulls = sysconv(bit, o.status & 0x40000), -- OBJMOD_ANSINULLS
uses_quoted_identifier = sysconv(bit, o.status & 0x80000), -- OBJMOD_QUOTEDIDENT
is_schema_bound = sysconv(bit, o.status & 0x20000), -- OBJMOD_SCHEMABOUND
uses_database_collation = sysconv(bit, o.status & 0x100000), -- OBJMOD_USESDBCOLL
is_recompiled = sysconv(bit, o.status & 0x400000), -- OBJMOD_NOCACHE
null_on_null_input = sysconv(bit, o.status & 0x200000), -- OBJMOD_NULLONNULL
execute_as_principal_id = x.indepid
FROM sys.sysschobjs o
LEFT JOIN sys.syssingleobjrefs x ON x.depid = o.id AND x.class = 22 AND x.depsubid = 0 -- SRC_OBJEXECASOWNER
WHERE o.pclass <> 100
AND ((o.type = 'TR' AND has_access('TR', o.id, o.pid, o.nsclass) = 1)
OR (type IN ('P','V','FN','IF','TF','RF','IS') AND has_access('CO', o.id) = 1)
OR (type IN ('R','D') AND o.pid = 0))
You can see that this view queries another system object sys.sysschobjs that, I think, is the system table used to store definition of views.
Note 1: Using INFORMATION_SCHEMA.VIEWS to find definition of a view is not a reliable method because INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION column definition is convert(nvarchar(4000), object_definition(object_id)) (max. 4000 chars).
Note 2: Instead, you should use sys.sql_modules.definition column: definition = object_definition(o.id). If you look at object_definition function (link) you will see that return type is nvarchar(max).
If you mean the tables the view produces then the answer is that they aren't stored at all. A view is just a query, and that is all it stores. When you query a view the db engine just fetches your view query's results and then queries those.
DB engines can store 'materialized' views, but that's a different topic.
In a system table.
The following query will retrieve them...
SELECT TABLE_NAME as ViewName,
VIEW_DEFINITION as ViewDefinition
FROM INFORMATION_SCHEMA.Views
To view edit them normally you would look in the view folder under tables in studio manager.
You can create/edit them from this folder using the designer or write scripts.
View is a simple SQL statement that is stored in database schema (INFORMATION_SCHEMA.Views). So when ever we call the view the SQL statement gets executed and return the rows from main physical table.
You can also tell the view as a Logical table that store the defination (the sql statement) but not the result.
You can see the defination using below statement, as said by Dan above, Only if the view defination is Not encrypted:
SELECT TABLE_NAME as ViewName, VIEW_DEFINITION as ViewDefinition FROM INFORMATION_SCHEMA.Views
More details on View # MSDN.
Up until today I've been able to run queries without using the [databaseName].[dbo].[fieldName] syntax. And all of a sudden, if I use select * from myTable I get an error for an invalid object. I can't possibly think of something that happened between shutting down my PC yesterday and today. Anyone know anything about this?
Msg 208, Level, 16, State 1 Line 1
Invalid object name 'mytable'
It's only been since today that I have to include the database name in the query. There are no other connections open and no other users of this instance of SQL Server.
I think you mean a query of the form select [fieldName] from [databaseName].[dbo].[mytable]
Here are some possible things to look out for:
Make sure that you are in the correct database context / catalogue (i.e. use [databasename], or select the correct database from the Available Databases drop down in SSMS)
Ensure that if you have a case sensitive collation on your database that the object names in your query match the exact case.
Check that the default schema for your user hasn't changed on this database. Although the default schema is usually [dbo], it can be changed.
Edit : More ideas:
Do SELECT DB_NAME() to see what the current database name is.
Check to see if someone has dropped the table or view entirely, e.g. from the target database, run:
Select * from sysobjects where name = 'myobject'
OR
Select * from sys.tables where name = 'mytable'
OR
Select * from INFORMATION_SCHEMA.TABLES
I have an Access database in which I drop the table and then create the table afresh. However, I need to be able to test for the table in case the table gets dropped but not created (i.e. when someone stops the DTS package just after it starts -roll-eyes- ). If I were doing this in the SQL database I would just do:
IF (EXISTS (SELECT * FROM sysobjects WHERE name = 'Table-Name-to-look-for'))
BEGIN
drop table 'Table-Name-to-look-for'
END
But how do I do that for an Access database?
Optional answer: is there a way to have the DTS package ignore the error and just go to the next step rather than checking to see if it exists?
SQL Server 2000
I'm not sure whether you can query the system objects table in an Access database from a DTS package.
If that doesn't work, why not just try doing a SELECT * from the Access table in question and then catch the error if it fails?
Try the same T-SQL, but in MS ACCESS the sys objects table is called:
MSysObjects.
Try this:
SELECT * FROM MSysObjects WHERE Name = 'your_table';
and see if it works from there.
You can take a look at these tables if you go to Tools -> Options -> View (a tab) -> and check Hidden Objects, System Objects. So you can see both. If you open the table, you should see your table names, queries, etc. Do not change this manually or the DB could panic :)
Martin.
P.D.: Your If Exists should also check of object type:
IF EXISTS (SELECT * FROM sysobjects WHERE id = object_id(N'[dbo].[Your_Table_Name]') AND OBJECTPROPERTY(id, N'IsUserTable') = 1)
Microsoft Access has a system table called MSysObjects that contains a list of all database objects, including tables. Table objects have Type 1, 4 and 6.
It is important to reference the type:
... Where Name='TableName' And Type In (1,4,6)
Otherwise, what is returned could be a some object other than a table.