storage location of server objects in SQL Server - sql-server

Subquestioning [1] and [2].
Where does SQL Server store server objects?
And why there?
Update:
This question is defined as subquestion and in context of cited questions...
Should I understand the answer that sql_policy_trigger, shown under Server Objects\Triggers in Object Explorer of SSMS (MS SQL Server R2), is stored in master database?
=====Update2:
Please give me the references to msdn docs in your answer(s).
It is not obvious that system or server configuration objects, meta-information or catalogs are stored in database(s). For ex., FTS catalog is not stored in database but in file (system), etc.
[3] (BOL2005-2008R2) tells that:
"master Database
Records all the system-level information for an instance of SQL Server"
"In SQL Server, system objects are no longer stored in the master database; instead, they are stored in the Resource database"
So, it is instance-wide (but not server-wide) and it clearly mentions "system".
As well as it hints that "they" are not stored in master database.
Also, I would like to understand why SSMS permits to script server objects (for ex., right-click in Object Explorer under Server Objects --> Triggers on syspolicy_server_trigger --> Script Server Trigger as...---> ) while, for ex., system views do not have such possibility.
Cited:
[1]
Where does a Server trigger save in SQL Server ?
Where does a Server trigger save in SQL Server?
[2]
“system objects” vs. “server objects” in SQL Server - terms definitions?
"system objects" vs. "server objects" in SQL Server - terms definitions?
[3]
master Database
[3a]
(SQL Server 2008 R2 Books Online)
http://msdn.microsoft.com/en-us/library/ms187837.aspx
[3b]
(SQL Server 2005 Books Online)
http://msdn.microsoft.com/en-us/library/ms187837(v=SQL.90).aspx

sys.objects, sys.indexes etc (as per your trigger question). See Object catalog views in MSDN
As for why, a relational database may as well use a relation structure to store information about itself, no? Apart from a few registry settings used on start up, almost every setting and object is stored in a table somewhere in SQL Server.
Examples:
sys.messages = error messages
sys.configurations = sp_configure
Edit, I had to dredge my memory about why this is so...
Rule zero in Codd's law
The system must qualify as
relational, as a database, and as a
management system. For a system to
qualify as a relational database
management system (RDBMS), that system
must use its relational facilities
(exclusively) to manage the database.
This ignores the "relational" puritans and zealots but explains why sys.objects etc are used.
Edit:
Making a guess at what OP really wants... server level objects are stored in the master database.

Related

SQL Server 2019 "Invalid object name sys.sysrowsets"

I get folowing error: SQL Server 2019 "Invalid object name sys.sysrowsets", then I tried to select data from sys.sysrowsets table.
I have sql server 2019.
Do you know how solve this?
Thank you
This is a system base table.
It still exists in SQL Server 2019
Exists in every database. Contains a row for each partition rowset for
an index or a heap.
It can be seen in the execution plan when selecting from sys.partitions but (as the docs explain)
To bind to a system base table, a user must connect to the instance of
SQL Server by using the dedicated administrator connection (DAC).
Trying to execute a SELECT query from a system base table without
connecting by using DAC raises an error.
So if you have appropriate permissions then technically the software can run the SELECT by connecting to the DAC port.
It is not advisable to do this though. Having software that routinely connects via the DAC rather than use documented views is not a good idea and is explicitly warned against in the docs
Important
Access to system base tables by using DAC is designed only for
Microsoft personnel, and it is not a supported customer scenario.
What is this software doing for you? Why is it accessing base tables directly rather than using documented interfaces?

How to continually synchronize two SQL Server databases?

I have a SQL Server database that contains a lot of data, with many tables, views, triggers, stored procedures etc. Some of the tables are: 'users', 'cart', 'stores' etc.
In the same time, I need to have a copy of this database, which should be synchronized from the main table, on certain time. So the changes in my primary database should be reflected in the copy of my database a few times per day. Additionally, if there is a change in the 'users' table, this update should trigger the synchronization immediately.
In the copy of the database, I have a few more tables 'managers', 'schools' etc, which are not present in the primary database. While synchronizing, these additional tables should not be changed at all, since were not present in the main database.
So let's take a look at these databases independently from the solutions that are using them. What I wonder is: what is the best way to set up such a synchronization? The database is huge, and querying the data for each database tables from one location to another does not seems as a good option. Is there any generic way of how to do this synchronization? And should this be done within a code, or maybe there is some trigger on the server where the database is placed (under control panel) or maybe via SQL Server itself? I am not sure what's the best option here, so please advise.
I am using the version
Microsoft SQL Server 2017 (RTM-CU9-GDR) (KB4293805) - 14.0.3035.2 (X64) Jul 6 2018 18:24:36
Web Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: ) (Hypervisor)
you need to configure object level replication where you can select specific tables, stored procedures, views, etc. your primary data source will be called publisher and the secondary
location where you will store this change will be called subscriber.
Replication can fulfill your requirements completely.
There are many types of replication and assuming the changes will not be happening from secondary location, transactional replication would suit your requirement best.

How to link Access table in SQL Server

I have a SQL database and I want to link an Access table in the SQL database. Most of the online articles and videos show how to link the two databases from Access but not from SQL. I want the access table linked in SQL database so that every time the table gets updated in Access, the table in SQL server gets updated as well. Thanks!
You can do that. It's called a Linked Server and will link your Access database in SQL Server where you typically will create a view to read the Access tables to avoid the DatabaseName..TableName syntax otherwise needed.
However, it will probably not work for you because SQL Server will insist on opening the linked Access database exclusively, meaning that you cannot open it later from your Access application. And if you open it first in Access, an attempted reading from SQL Server will fail because SQL Server cannot get exclusive access.
You may argue, that a shared access should be possible, and connection parameters indicate this, but I haven't found a way to achieve this.
So, as others have mentioned, you may have turn this upside/down, and use, say, ODBC to link the SQL Server tables in your Access application, and then let this take care of the maintenance of the SQL Server tables.
It must be like this (SQL SERVER) => (MS Access)
and yes you are correct, it's called linked tabled in Ms Access. In order to link a table from another database, you must have
Correct drivers installed. (ODBC)
Know the login details of your SQL server and have sufficient permission in SQL server
Go to MS Access -> External data -> ODBC Databse -> link to the data source by creating a linked table ->
Now you can select a DSN file where your sql server credentials are saved, or you can make "new" and follow the steps to get connected to the SQL server.
Once connected, you will be presented with a list of all the tables from SQL server. Select the table you want to link and finish the wizard.
You now have SQL table connected in MS Access and can input data directly.

What is the typical usage of View > Server Explorer vs View > SQL Server Object Explorer?

What is the connection (no pun intended) or relation (NPI) between the Server Explorer and SQL Server Object Explorer "Views" (no pun intended) available from Visual Studio?
When I want to examine a database I can select View > Server Explorer, and the main categories/folders are:
Azure
Data Connections
Servers
SharePoint Connections
In Data Connections, there are items such as duckbill.PlatypusData.dbo, which contain the following folders:
Tables
Views
Stored Procedures
Functions
Synonyms
Types
Assemblies
If, OTOH, I select View > SQL Server Object Explorer, there are these two categories of items:
SQL Server
Projects
Beneath SQL Server, duckbill has these folders:
Databases
Security
Server Objects
In Databases.PlatypusData there are these subfolders:
Tables
Views
Synonyms
Programmability
Service Broker
Storage
Security
So, unique to the View > Server Explorer > Data Connections > [database name] are these items:
Stored Procedures
Functions
Types
Assemblies
Unique to View > SQL Server Object Explorer > SQL Server are these items:
Programmability
Service Broker
Storage
Security
The commonality between the two "Views" are:
Tables
Views
Synonyms
So, for example, to view/run Stored Procedures I need to use View > Server Explorer. What is the "cutoff point" between usage of these two Views. Is one for a certain type of developer/development, and one for something else? Are they both intended for distinct "Roles" (NPI)?
In my view the view from Visual Studio is just an extension to the traditionally available SQL Management Studio. I think both of them have their own uses and purposes. Visual Studio would be typically used by application programmer to quickly query the data and examine the objects in SQL Server. Or by a DevOps person to view various other things like the EventLog or Services Statuses under the Server Node.
Whereas, SQL Management Studio would be used by SQL only person. Who does not have anything to do with application development as such.
I dont think there is any cutoff point as such. Its a option which is there. However, seeing the development Microsoft is making i wont be surprised if they will merge two together some day. I remember back in old days there was Query32.exe which was used to query SQL Server data outside of SQL Management studio.

SQL Server : Linked Server Querying

Sorry if this is a newbie question.
Situation : I have a local SQL Server linked to a main SQL Server (reason, I don't have access to create views/sps/etc on main server)
I have defined views1, views2, views3 on local SQL Server which entirely relates tables/views on the main server (NO local SQL Server tables)
Q: how will a join on view1 and view2 or view3 materialize? That is, will the results of each view be pulled into the local server and joined locally (even though all referenced tables are on the main server)? Are there any guarantees one way or the other, OR is it entirely up to the optimizer ?
Q: if the view referenced a UDF on the local server, [ how ] would the process above change ?
Many thanks.
If all the tables involved in the query are on the same remote server (and that server is an Microsoft SQL Server), the JOIN operation should be performed remotely. To find out if it is executed locally or remotely, you can look at the execution plan (it should contain only a "Remote Query", no joins) or use Profiler on the remote server (if you have sufficient rights).
If the JOIN operation is perfomed locally, you may be able to change the query plan if you use the REMOTE JOIN hint (although this hint only makes sense if one of the tables is a local one). Getting an efficient query plans depends on having updated statistics and in the case of a distributed query (joining a local table to a remote table), this also means having enough rights to read the remote statistics: "If the linked server is an instance of SQL Server, to obtain all available statistics, the user must own the table or be a member of the sysadmin fixed server role, the db_owner fixed database role, or the db_ddladmin fixed database role on the linked server".

Resources