I have an Excel workbook which is used for data reconciliation from SQL server. There are 3 different environments which I need to reconcile data.
I have a stored procedure which pulls the specific data, Currently my "DATA CONNECTION" is pointing to a TEST Environment. However I need to be able to dynamically change my environment between TEST, UAT, PROD AND DEV.
Can anybody please help me out ?
In Data > Connections you can see and change your connections.
If you saved your Data Connection to a file (odc) then you can just switch the Connection file in the Connection Properties > Definition. Otherwise, you can change the Connection string itself.
Related
We have a Server A and a Server B.
In Server A we have our ERPs made in Access and VBA.
In Server B we have an instance of SQL Server that needs to stay in that server.
Some Access databases need to link to some tables from that SQL Server instance and I don't want the password to be stored in the MSysObjects table, so I cannot manually link the tables checking the save the connection option.
I saved the connection string in a table with password obfuscation. With that connection string I re-link the tables on startup.
The instance is accessed through it's IP, not the name of the instance. If I use the name of the instance it doesn't work.
It works for me but not for other users except one.
The SQL Server instance has been properly configured to allow remote connections, the ports have been opened and rules added to firewall. If it wasn't properly configured it wouldn't work for me and the other user, so I'm pretty confident in that. The same with the connection string and the methods to stablish the connection in Access.
What I've tried:
Installing the SQL Native Client 11.0.
Installing a full SQL Server Express.
Configured the SQL Browser service to star automatically instead of being disabled.
Step 1 did not work for any user. Step 2 did work for one user but not for the rest. Step 3 did not had any effect. For me I had it installed in my machine since forever, so it doesn't apply.
If I try to do the same with a SQL Server instance in our LAN it works for every user, but not when the instance is in a remote server.
Note I have limited knowledge. Maybe I say something that does not make sense.
Ok, a few things:
Installing the SQL Native Client 11.0.
Ok, then you have to re-link the tables - choose the new driver. A refresh of the linked tables is NOT sufficent. And this ALSO means that each work station ALSO now must have native 11 instlled. And if you say decide to link using native 17 (a much newer odbc driver), then AGAIN YOU must install this native driver on each work station. While you can install multiple sql drivers on each workstation, the driver you used to link the tables MUST ALSO be installed and exist on each work station.
Installing a full SQL Server Express.
Why? What would installing a copy of sql server have to do with OTHER sql servers on other machines that you are attempting to connect to? You think installing sql server on a machine effects the sql server running say on amazon.com? So, this move makes no sense at all.
You are attempting to connect to some instance of sql server running on some other computer. Makes no sense nor will it help to install some copy of sql server that you not using, not connecting to, and that has zero to do with this issue.
Configured the SQL Browser service to star automatically instead of being disabled.
Where? The browser service is set to run and startup on the server and SAME machine where sql server is installed and running. So, yes, without question, those two sql servers A, and B most certainly MUST have the sql browser service running. That service is what allows the client computers to connect to that running instance of sql server. In the past, older (previous) versions of sql server would allow a default connection, but now in near all cases, you MUST ensure that the sql browser service is running on that computer that also has the database you are attempting to connect to.
it's worth to note that the instance is accessed through it's IP, not the name of the instance.
No, you likly have this incorrect. There are two part.
The server name - and then the "instance" of sql server running.
While you can swap out (not use) the server name, you STILL WILL NEED to specify the sql server instance.
So, you can use this format:
myservername\SQLEXPRESS
Or, you can replace the server with a IP address, but you STILL NEED the sql server instance. (by default, it is SQLEXPRESS - but you have to check what the instance of sql server database is).
192.168.1.30\SQLEXPRESS
So while you can use IP or server name - it is often more reliable to use the IP address, but that does NOT get you off the hook from having to specify the sql instance you connect to. Again, previous editions of sql server often allowed a "default" instance, and you did not in general have to specify the "instance", but now you do. And to be double clear, when using such a instance, that sql server needs to be running the sql browser service. (in fact, the browser service is what translates the incoming request to the given and correct instance of sql server).
I DON'T want the password to be stored in the MSysObjects table,
You don't have to, and in fact should NOT include the uid/password in your connection string. And in fact ZERO reason exists to do so.
What you do is execute a one time logon, and THEN link the tables without UID/password. This is not only a great idea, but it also means that your uid/password is not included in the connection strings, but also means users can't get at, or even by accident see/get the uid/password.
It also means that say someone where to launch a copy of access, and import the linked tables from this applcation. When they attempt to use the linked tables, they will NOT work.
So, then how do linked tables work without a password? (and this ALSO by the way saves you from having to re-link tables on startup!!!).
The way this works, is you in code execute a one time logon to the server on startup. That means you can either:
Prompt the user for their sql UID/password.
or
Have in code, the uid/password. (or perhaps in a text file y ou read on startup. You can thus hide, or encrypt or whatever for that uid/passwords.
Then in your startup code, you execute a one time logon. Once you done this, then all linked tables will now work - and work without having uid/password.
since you have two servers then you need to execute two logons, one for server A, and one for server B. But, once again, as long as the linked tables exist, then they will work.
Now, there are "longer" articles on how to use this logon idea, and then not have to include, or re-link your tables for the SQL uid/password.
The basic code to execute a logon is like this:
Function TestLogin(strCon As String) As Boolean
On Error GoTo TestError
Dim dbs As DAO.Database
Dim qdf As DAO.QueryDef
Set dbs = CurrentDb()
Set qdf = dbs.CreateQueryDef("")
qdf.connect = strCon
qdf.ReturnsRecords = False
'Any VALID SQL statement that runs on server will work below.
' this does assume user has enough rights to query built in
' system tables
qdf.sql = "SELECT 1 "
qdf.Execute
TestLogin = True
Exit Function
TestError:
TestLogin = False
Exit Function
End Function
Keep in mind, that ONCE you acheived a legal logon, then EVEN addtional logon attempts will return true.
Not usually a big deal, but this means you supply a valid connection to above, and if it logs on and works - then now all your linked tables (without uid/password) will work.
I note the above issue that ONCE you done the logon, then all 2nd or more times running the above will work (even if bad or incorrect!!! - DO NOT forget this tip!!!). (this can confuse the daylights out of a developer, since they execute logon, (or open a table). Then they test above routine with a BAD uid/passwords, and it works!!!
So, you have to EXIT access to clear out the password cache - no other way.
So, keep the above tips in mind.
I have an Azure Data Factory pipeline that contains copy data task. The task copies the data from Azure Blob storage to SQL Server Table. The SQL Server is hosted on-prem and hence is accessed through integration runtime.
I tested the connections to both Azure Blob Storage and SQL Server from Azure Data Factory and they work.
However, when I try to execute the copy task I get the following error:
The object (covered in black for confidentiality) is the name of the table I want to write to in SQL Server. I can confirm that the table exists. I can confirm that the user that is the integration run time is using to access SQL server is having the required permissions to write to the table.
This is not an issue with Data factory, as you say your connection is successful it seems to be true.
It more of seems to an issue with either not using the correct database or you do clearly have no access on the table.
Can you use the same database credentials login using SSMS and try running select/update queries?
Also can you check if the auto increment is true?
Please find this link for your reference - > https://support.microsoft.com/en-us/topic/error-message-when-you-try-to-insert-data-into-a-custom-table-in-microsoft-dynamics-nav-cannot-find-the-object-navdbname-dbo-companyname$-tablename-because-it-does-not-exist-or-you-do-not-have-permissions-70dc2a61-c5f7-a85e-ae24-0b4d8931d9ef
A few things you can do to further check if the table is accessible.
Open the related Dataset that is used as 'Sink'
In Connection tab of the dataset, try both 'Test connection' and 'Preview data', as in the image below.
In Schema tab, try the 'Import schema' button, as in the image below.
I have an Excel file with a SQL query to retrieve information from our SQL Server database. I want this Excel file to be available to anyone on the network.
I tested this a couple of times and it is not creating the connection on any PC but mine. I found a few answers that I thought would resolve the problem but whenever I attempt to change the connection string in Excel it reverts back to the original string.
Here is the current connection string:
DRIVER=SQL Server;SERVER=SERVER\SQLEXPRESS;UID=<My User ID>;Trusted_Connection=Yes;APP=2007 Microsoft Office system;WSID=<My WS ID>;DATABASE=<Database Name>
The main person I would like to have access to this file also has permissions to access the database from SQL Server Management Studio. What I found from searching said I should set the security to Windows Authentication and change the connection string to something along these lines:
DRIVER=SQL Server;SERVER=SERVER\SQLEXPRESS;Integrated Security=SSPI ;DATABASE=<Database name>
However when I attempt to change the connection settings in my Excel file it reverts back to the original string. What would be causing it to revert back to the original connection string after I change it and is the second example correct?
Thanks in advance
I'll leave the question open since it could help someone else down the road. I got this to work by changing the connection string inside of the connection file to:
DRIVER=SQL Server;SERVER=SERVER\SQLEXPRESS;Integrated Security=SSPI ;DATABASE=<Database name>
The line Integrated Security=SSPI took care of the sharing issues between computers.
I'm making my first report with Sql Server Reporting Services (2012) and have managed to create two datasets successfully, each one connecting to the same Data Source. This Data source uses an embedded connection and the user can select the server and Database at runtime. The connection string is as follows
="data source=" & Parameters!ServerName.Value & ";initial catalog=" & Parameters!DatabaseName.Value
The two parameters in question are created and everything works fine for these two datasets, the report displays with a choice of servers and databases and displays the relevant data when I click on Show Report.
However, when I try to add a third DataSet (I need a separate SQL command to pull separate data for the footer and header) this one doesn't connect.
I've tried the following:
-Right click on the existing data source to create the data set, selecting the existing source. When I open the query designer it fails to connect
-Create a new data source with a fixed connection string. This works but is not what I want
-Create a new data source with another name and the same connection string as the original. This fails, and is not really what I want anyway.
Is there anything obvious I'm overlooking? For info, I originally had the first two data sets created and running with a fixed connection string before I changed the connection string in the data source to use a dynamic one. I've restarted the report designer since, though, and the first data sets continue to connect using the dynamic string. I tested with multiple databases just to be sure
Never done this before myself but the last 2 sentences in the section Expression-Based connection Strings msdn.microsoft.com/en-us/library/… looks to me like you need to revert to a fixed connection string to do your update then change back to dynamic when ready to publish?
I'm trying to build a connection string for a test environment that will connect to the local SQL Server instance on different machines. The purpose of this is so that a developer can checkout the code from TFS, build it, and run the testcases, connecting to his local DB. The problem is that different developer's machines may have different SQL Server setups. In particular, some may be running the full server, others may be running SQL Server Express.
I'm trying to right a utility routine that will take template connection string (e.g., Data Source=(local); Initial Catalog= myDB; Integrated Security=SSPI;) and modify the Data Source to work with the local server.
I've tried using SmoApplication.EnumAvailableServers() (returns an empty table, regardless of whether I user true or false parameters), and SqlDataSourceEnumerator.GetDataSources() (returns 2888 servers from the network, but none on the local machine), SQLCMD -L (returns nothing).
Any suggestions?
In the alternative, is there an easy way to tell whether a particular connection string will connect to a server (without waiting for it to timeout if it doesn't). If I could find the answer to that, I could try the likely suspects until I got one to work.
you might try to get the connection string as following:
Create a new blank file and name it test.udl.
Double click on it, and a "Data Link Properties" dialog should appear.
On "Providers" tab, select "Microsoft OLE DB Provider for SQL Server" or "SQL Native Client"
On "Connections" tab, try various settings and use the "Test Connection" button to test them. Click "Ok" when it works.
Open the test.udl file in Notepad and copy the line that starts with "Provider=" into your Web.config "ConnectionString" value, BUT delete the little part that says "Provider=SQLNCLI.1;"
If you want each developer to work with their own local SQL server, then the ADO connection string should have the Data Source set to localhost
... ; Data Source=localhost; ...
Additionally, to get a list of current servers, go to the command line and run
osql -L
You can look in the registry to find all local SQL Server instances. This key contains the list: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL.
Each named instance will have a value in this key. For named instances the name of the value is the same as the name of the instance. For the default instance the value will be named MSSQLSERVER.
This will do the trick:
Data Source=.\SQLEXPRESS