Getting current connection properties in SQL Server - sql

In MS SQL Server, the Database Properties dialog has the "View Connection Properties" link over on the left. Clicking that brings the "Connection Properties" dialog with properties of the current connection, such as Authentication Method, Network Protocol, Computer Name, etc...
Is there a way to get that information programmatically by running a sql query? What would that query look like?

SQL 2005 and after you interrogate sys.dm_exec_connections. To retrieve your current connection properties you'd run:
select * from sys.dm_exec_connections
where session_id = ##SPID
The field values depend on the protocol used to connect (shared memory, named pipes or tcp) but all contain information about authentication method used, protocol and client net address.

Yes you can, but it depends on which property you are after as the ones displayed in the connection properties UI come from several places.
It uses several queries (such as xp_msver and select suser_sname()) to get hold of some properties, but it also uses the xp_instance_regread stored procedure to get hold of some values from the registry of the server.
Pretty much everything that is done is management studio when interacting with the SQL engine can be done using SQL. Starting a profiler session and doing the actions in the UI will uncover what (sometimes obscure/undocumented/unsupported) SQL is being run.

From client tool perspective you could use CONNECTIONPROPERTY:
For a request that comes in to the server, this function returns information about the connection properties of the unique connection which supports that request.
SELECT ConnectionProperty('net_transport') AS [Net transport],
ConnectionProperty('protocol_type') AS [Protocol type];
DBFiddle Demo

I think the answer is 'no'.
Computer information is stored on the computer.
Connection information is most likely stored in a configuraton file or in MS SQL Server.
But have a look at the MSSQL system tables and see what properties they have.

Related

Data integration between IBM AS400 to SQL Server database

I'm a web developer that has been tasked with creating some sort of mechanism for moving data from an IBM AS400 to a SQL server. Unfortunately, linked servers are out of the question in this case as the SQL Server is just Standard Edition (db2 providers not available in this version) and the AS400 server is on a separate server. I've researched adding some sort of trigger on the AS400 table that calls a web service that would insert data into the SQL server, but that doesn't seem like the best method. Does anyone have any suggestions on the process to get the data from the AS400 to the SQL Server when it is committed to the AS400?
This solution assumes you are familiar with SQL Server Integration Services (SSIS):
Connection to AS400
Create a new ADO.Net connection Manager
Set the Provider to .Net Provider --> ODBC Data Provider
Create a DSN (Control Panel -->Administrative Tools-->Data Sources ODBC -->System DSN)
In the connection manager for Data source specification select the DSN created. Provide the login information.
Test the connection.
Data flow source:
Use the DataReader source
In Advanced Editor select the Ado.Net connection manager just created.
In Component Properties tab --> Custom properties, in SQLCommand specify the required query string (select * from DatabaseName.TableName)
Check the column mappings for accuracy
Go to Input and Output properties -->Data reader output -->External columns (Select the columns which were of type varchar in the table, they will now be of the datatype UnicodeString (DT_WSTR). This is because by default DataReader reads strings as unicode strings. This implies that in the destination table in SQL these columns must be of type unicode i.e NVARCHAR instead of VARCHAR)
Answer sourced from www.sqlservercentral.com/Forums
I synchronize my web applications with an IBM i. But I have my own database design and wrote a sync program on the Windows side.
Having the same database design I wonder why I would need a copy on SQL server. I would access the IBM directly. Install the drivers as #Kamran Farzami suggested and use them. That way there would be no lag between writes on the mainframe and your queries.
If a lag is acceptable for you and you can't access the IBM i directly, I see three main options:
Pull the data from your Windows system with the OLE DB driver. Using the .NET driver you can use the relative record number (RRN) to remember where you stopped synchronizing.
Read the journal files and make them available by creating a webservice on the IBM i.
Read the journal files in a scheduled job and push the changes from the journal to a webservice which updates the SQL server.
Option 1 only works if the files you sync are not reorganized. The RGZPFM command changes the record numbers. If that's okay, you can get the RRN in your SELECT statement: select *, RRN(MYTABLE) as RRNMYTABLE from MYTABLE
The web service server is included in OS400 since V5R4. So you should be able to use option 2.
I've done something similar where the SQL server was in a remote (Honduras) location where the internet connection was unreliable. It was a short VB program, using the OLE DB driver, running on the server that connected to the AS400 when it was available (or "slept" when the connection was down). When available the program would update/synchronize a uniquely keyed mirror file. Another program uploaded individual transaction records to a separate table (file).
We'd also periodically update SQL Server master tables (i.e. item master) from the AS400. That also utilized a VB program (could be any language using the driver) initiated on the server. It isn't exactly elegant, but more practical than an AS/400 trigger to a web service, I believe.

MS SQL: What is the easiest/nicest way to create a linked server with SSMS?

I am a beginner with SQL so I struggle with the MSDN description for creating a linked server in Management Studio.
I whant to link a SQL Server into another to use everything from ServerB on ServerA to e.g. provide one location other systems can connect to.
Both servers are in the same domain and both server have several databases inside.
When I start creating a linked server on ServerA in the general tap I select a name for the linked server and select SQL Server as Server type.
But I struggle on the Security tap. I have on both servers sa privilege so what is to set here?
Or which role should I take/crate for this connection?
My plan is to create views in a certain DB on ServerA with has also content of ServerB inside.
This views will be conusumed from an certain AD service user.
I already added this service user to the security on ServerA where the views are stored.
Do I also have to add this user somewhere on the linked ServerB?
I would recommend that you use Windows Authentication. Activate Security Delegation.
In the Security tab, choose "Add". Select your Windows user and check "Impersonate".
As a quick and dirty solution, you can choose "Be made using this security context" from the options list and enter a SQL Login which is valid on the remote server. Since quick and dirty solutions tend to last, i would strongly recommend to spend some time on impersonation.
In Server Objects => right click New Linked Server
2. The “New Linked Server” Dialog appears. (see below).
3. For “Server Type” make sure “Other Data Source” is selected. (The
SQL Server option will force you to specify the literal SQL Server
Name)
Type in a friendly name that describes your linked server (without spaces). – Select “Microsoft OLE DB Provider for SQL Server”
Product Name – type: SQLSERVER (with no spaces)
Datasource – type the actual server name, and instance name using this convention: SERVERNAMEINSTANCENAME
ProviderString – Blank
Catalog – Optional (If entered use the default database you will be using)
Prior to exiting, continue to the next section (defining security)
Click OK, and the new linked server is created
The easiest way would be to specify to make the connection using the current context, i.e. the user loging on to ServerA:
EXEC master.dbo.sp_addlinkedserver #server = N'ServerB', #srvproduct=N'SQL Server'
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'ServerB',#useself=N'True',#locallogin=NULL,#rmtuser=NULL,#rmtpassword=NULL
This however assumes that users accessing the linked server connection have the correct privileges on ServerB (part 2 of your question) - otherwise you'd need to use impersonation as described by Martin K.

Is it possible to monitor and log actual queries made against an Access MDB?

Is it possible to monitor what is happening to an Access MDB (ie. what SQL queries are being executed against it), in the same way as you would use SQL Profiler for the SQL Server?
I need logs of actual queries being called.
The answer depend on the technology used from the client which use MDB. There are different tracing settings which you can configure in HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Engines\ODBC http://office.microsoft.com/en-us/access/HP010321641033.aspx. If you use OLEDB to access MDB from SQL Server you can use DBCC TRACEON (see http://msdn.microsoft.com/en-us/library/ms187329.aspx). I can continue, but before all you should exactly define which interface you use to access MDB.
MDB is a file without any active components, so the tracing can makes not MDB itself, but the DB interface only.
UPDATED: Because use use DAO (Jet Engine) and OLE DB from VB I recommend you create JETSHOWPLAN regisry key with the "ON" value under HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\JET\4.0\Engines\Debug (Debug subkey you have to create). This key described for example in https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5064388.html, http://msdn.microsoft.com/en-us/library/aa188211%28office.10%29.aspx and corresponds to http://support.microsoft.com/kb/252883/en allow trace OLE DB queries. If this output will be not enough for you you can additionally use TraceSQLMode and TraceODBCAPI from HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Engines\ODBC. In my practice JETSHOWPLAN gives perfect information for me. See also SHOWPLAN commend.
UPDATED 2: For more recent version of Access (like Access 2007) use key like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Access Connectivity Engine\Engines. The tool ShowplanCapturer (see http://www.mosstools.de/index.php?option=com_content&view=article&id=54&Item%20%20id=57, to download http://www.mosstools.de/download/showplan_v9.zip also in english) can be also helpful for you.
If you're accessing it via ODBC, you can turn on ODBC logging. It will slow things down a lot, though. And it won't work for any other data interface.
Another thought is using Jet/ACE as a linked server in SQL Server, and then using SQL Profiler. But that's going to tell you the SQL that SQL Server processed, not what Jet/ACE processed. It may be sufficient for your purposes, but I don't think it would be a good diagnostic for Jet/ACE.
EDIT:
In a comment, the original poster has provided this rather crucial information:
The application I am trying to monitor
is compiled and at a customer's
premises. I am trying to monitor what
queries it is attempting against an
MDB. I cannot modify the application.
I am trying to do what SQL Profiler
would do for a SQL Server.
In that case, I think that you could do this:
rename the original MDB to something else.
use a SQL Server linked server to connect to the renamed MDB file.
create a new MDB with the name of the original MDB and link to the SQL Server with ODBC.
The result will be an MDB file that has the same tables in it as the original, but they are not local, but links to the SQL Server. In that case, all access will be going through the SQL Server and can be viewed with SQL Profiler.
I don't have a clue what this would do to performance, or if it would break any of the data retrieval in the original app. If that app uses table-type recordsets or SEEK, then, yes, it will break. But this is the only way I can see to get logging.
It shouldn't be surprising that there is no logging for Jet/ACE, given that there is no single server process managing access to the data store.
Keep in mind that the file sitting on your hard drive is simply a windows file. So, there is a big difference between a server based system and that of a simple text file, or Power Point file, or in this case a mdb file just sitting on the drive.
However you can get the jet engine to display its query optimizeing via showplan.
How to do this is explained here:
http://www.databasejournal.com/features/msaccess/article.php/3658041/Queries-On-Steroids--Part-IV.htm
The above article also shows how to access the jet disk read statistics, which I also find extremely useful for optimizing things.
Just remember to turn off that data engine logging system when you’re not using it as it creates huge log files…
you could write your own profiler, based on a "transaction" object that will centralize all instructions sent to the database, You'll end up somewhere with a "transaction.execute" method, and a transaction table in your access db. This table can then be used to collect transaction's instructions, start time, end time, user sending the instruction, etc.
I'd suggest upsizing the tables to SQL Server. There is a tool from the SQL Server group that is better than the Upsizing Wizard that is included with Access.
SQL Server Migration Assistant for Access (SSMA Access)
Also see my Random Thoughts on SQL Server Upsizing from Microsoft Access Tips page

How to Inspect ODBC communication, to see the SQL being passed through?

Is there a tool for windows that we can use to inspect any SQL commands that go through a particular ODBC data source?
You can make ODBC log out everything it's doing:
http://support.microsoft.com/kb/274551
http://msdn.microsoft.com/en-us/library/ms711020%28VS.85%29.aspx
You can also do it programmatically:
... One can do this by calling SQLSetConnectAttr and set the SQL_ATTR_TRACE attribute in the connection to SQL_OPT_TRACE_ON. So, by doing this you would be enabling/disabling it for the connection duration.
http://decipherinfosys.wordpress.com/2009/01/17/odbc-tracing/
If you're using SQL Server, look at the SQL Server Profiler. Profiler allows you to monitor/trace all communications between your application and the SQL Server, including which procedures are called, parameter values, etc, without having to modify your application.
If you're using a different server, you should be able to find a sql proxy that will do the same thing.

TSQL command to connect to another server (SQL Server 2005)

Is there a TSQL command to connect to another server?
Or when you are in a Query Window, what are the Keyboard shortcuts to connect to another server and have a Query Window show up?
I have seen Ctrl+N pop up the Connect to Server dialog in some screens but when I am in a Query Window already and hit Ctrl+N it just opens up another Query Window.
The USE command lets you connect to other databases on the current server but is there a command that lets you connect to another server?
I am using SQL Server 2005.
You can use OpenDataSource with a linked server
OpenDataSource(provider_name, init_string)
For example
SELECT
FirstName,
Gender
FROM
OpenDataSource (
'SQLOLEDB',
'DataSource = NOLI\SQL2;UserID=myUserID;Password=myPassword'
).Organisation.dbo.Employees
From MSDN-
Like the OPENROWSET function,
OPENDATASOURCE should only reference
OLE DB data sources that are accessed
infrequently. Define a linked server
for any data sources accessed more
than several times. Neither
OPENDATASOURCE nor OPENROWSET provide
all the functionality of linked-server
definitions, such as security
management and the ability to query
catalog information. All connection
information, including passwords, must
be provided every time that
OPENDATASOURCE is called.
Either via the Menu...
Query > Connection > Change Connection
or via the mouse...
(Right Click Mouse Button) > Connection > Change Connection
Both will pop up the Connect to Database Engine dialog box
If your wanting to write some TSQL between servers then you'll need to create a Linked Server and then use OPENQUERY or OPENROWSET in your SQL. There are some good pointers in the previous posts on how to do this.
Another couple of options that may be viable depending on what you want to do are SQLCMD mode, and Registered Servers.
SQLCMD mode can be enabled under the query menu in SSMS. Once it's enabled you can do something like this with it:
:CONNECT SERVER1
SELECT ##SERVERNAME;
GO
:CONNECT SERVER2
SELECT ##SERVERNAME;
GO
With Registered Servers (should be under the View menu) you can set up groups of servers and execute queries against the groups all at once.
Both can be useful in many DBA scenarios, but I'm not sure if that's what you're after.
You have the choice of creating a Linked Server and use with OPENQUERY or use OPENROWSET.
If you are talking about, changing the connection to a query window, simply right-click in the query window and select change connection.
Once you have setup a linked server you can run TSQL against it by fully qualifying each table/view
select * from [Server].[Database].[Owner].Table
In this way you can talk to any server from any query window - if that's what you need. In most Sql you only ever supply the table, as everything else is defaulted. Using this technique you can even write join clauses between servers, as low as the distributed transaction coordinator (MSDTC) is running. Of course you'll only do that once to prove it works, as it runs incredibly slowly.