When my machine is reimaged or swapped out, I have to take a screenshot of each Data Source in my the Microsoft ODBC Administration tool to make sure I get it right on the new machine. Even going to a coworker's machine, using their settings might not work to connect to the same data sources because we might have different configurations (annoying, to say the least). Rather than taking a screenshot, there must be a way to output all those settings to a text file. Searching for an answer to my question gets me a lot of set-up answers and nothing that just outputs the current settings and configuration. I did find one that might help, if the values are listed in the registry file (http://stackoverflow.com/questions/3417142/command-line-to-change-path-to-mdb-file-for-ms-access-odbc-system-dsn)
Ideally, I'd like to use a batch file or vbscript. I'd like to see the text file say something like:
USER DSN
Data Source Name: MS Access Database
Driver: Microsoft Access Driver
Description:
Database: X:\Path\to\file.mdb
System Database: None
Driver Page Timeout: 5
Driver Buffer Size: 2048
Driver Exclusive: false
Driver Read Only: false
Default Authorization Username:
and so forth...
SYSTEM DSN
Data Source Name: data_warehouse
Driver: Adaptive Server IQ 12
Description:
... including other tabs like this ...
Database Server Name: data_warehouse
Database Start Line:
and so forth...
You could export the registry entries for odbc to a file and import it on the other machines e.g. on my Windows 7 64 bit machine the system data sources are in HKEY_LOCAL_MACHINE\Software\ODBC\odbc.ini. If you only want selective ones you can easily edit the exported file.
Alternatively, you could move to using file dsns. With file dsns you put all the settings for the DSN in a file and connect using FILEDSN=path_to_file instead of DSN=dsn_name.
Related
I have a microsoft access front end connecting to a SQL database for the backend. I have been using this setup for the last 4 years and I have recently run into issues with new associates not being able to use the tool due to our company retiring ODBC driver 17 from our internal systems. I don't understand what is the difference between ODBC Driver 17 and 18 that would cause version 18 to fail.
How the driver is used:
in ODBC Data source manager a manual link to our database is created. The associate enters a specific name for the link "Our_link" and in the Driver name it states "ODBC Driver 17 for SQL Server"
Then inside of our access front end we link to that driver like so:
Const ConStrSQL As String = "DRIVER={ODBC Driver 17 for SQLServer};Server=OurServer;Database=Our_DB;UID=User();Trusted_Connection=Yes;"
The issue I am having is when I try to create the ODBC connection in the data source administrator using ODBC driver 18 I get an error that states:
[![`"Connection Failed: The certificate chain was issued by an authority that is not trusted"`]
Not sure if this extra information would help but I also see the following:
SQLState: 08001
SQL Server Error -2146893019
Client unable to establish connection
Is this something I need to reach out to our database admin group and ask if they installed driver 18 on the server side?
I'm guessing it has to do with the changes to the encryption behavior with version 18, specifically that encryption is required by default. The recommended fix is to install a trusted certificate on your server[1], but if you don't want to deal with the DB Admins you might be able to still connect by specifying No (or optional) to Encrypt in your connection string.[2]
There is a chance that won't work the server is set to Force Encryption, but it sounds like the change is all on the client end. Ideally you would want the encryption working all the time, so if you are using a self-signed certificate add the public key from the SQL server to trusted certificates on the client machines.
[1]: https://techcommunity.microsoft.com/t5/sql-server-blog/odbc-driver-18-0-for-sql-server-released/ba-p/3169228)
[2]: https://learn.microsoft.com/en-us/sql/connect/odbc/dsn-connection-string-attribute?view=sql-server-ver16#encrypt
The 'fix' that was found with the help of one of my database admins is as follows:
In the data source manager there is an option to select that states "Trust Server Certificate"
Once that option is selected I was able to complete the rest of my DSM connection. One thing to note is I was receiving the previous error when trying to change the DEFAULT DATABASE option. The checkbox to "trust server certificate" is on the screen after that.. so I had to skip choosing my default database, check the box, then go back and select my default database for everything to work.
I haven't completed all my testing in Access to make sure everything works 100%, but my quick testing is very promising.
Sorry but I am failing at a very simple task right now.
I have the following database information:
database name
hostname
port
SID
TNS
User ID
password
I want to build a connection with the RODBC package.
According to the results of my google search i should do
conn<-odbcConnect(dsn, uid=***, pwd=***)
what is "dsn"? is this even the right way?
dsn is Data Source Name, which is a shortcut you may define on your machine to store key information about the connection. How you set up a DSN varies depending on your operating system.
I write scripts that run on multiple machines, so rather than use a DSN, I use odbcDriverConnect, via something like
odbcDriverConnect(connection="driver=[driver]; server=[server]; database=[database]; uid = [User ID]; pwd = [password]")
You'll need to know your driver name to make this work. Where to find this will depend on your operating system, as well as the flavor of SQL you are using.
I'd like to import that data contained in a sqlite file to PowerPivot. I downloaded an ODBC driver for sqlite (http://www.ch-werner.de/sqliteodbc/) to accomplish this. In PowerPivot I selected "Home" > "Get External Data" > "From Other Sources". I scrolled down to "Others (OLEDB/ODBC). Selected it and clicked next.
TheFor the connection string. I found this website: http://www.connectionstrings.com/sqlite and I tried the connection string at the bottom suggested for SQLite3 ODBC Driver:
DRIVER=SQLite3 ODBC Driver;Database=c:\Chinook_Sqlite.sqlite;LongNames=0;Timeout=1000;NoTXN=0;
SyncPragma=NORMAL;StepAPI=0;
(I'm using a sample database that I put at the root of my c:. The db if from here: http://chinookdatabase.codeplex.com/releases/view/55169 )
With this connection string when I Test the Connection I get the following error message:
The test connection failed because the provider could not be initialized. If you contact Microsoft support about this error, provide the following message: Faile to connect to server. Reason: Provider information is missing from the connection string. Add the provider information and try again.
I understand that the driver I installed is not found, but I don't know how to correct the connection string to point to the driver dll.
This solution came after many hours of research and trial-and-error. Though it came 2 years late, I am putting it up to help others trying to import information to Power Pivot 2013 from SQLite.
Step 1: Install SQLite ODBC Driver from here.
Step 2: Create a DNS by opening Windows' 'ODBC Data Sources Administrator' (you can find it under Windows > Administrative Tools). See here and here for more information. I have tried creating the DNS under both 'User DNS' and 'System DNS' - both work fine with Power Pivot.
Step 3: Open Power Pivot and do the following:
Click 'From other Sources' > 'Others (OLEDB/ODBC)' > Click on 'Build' button >
Under 'Provider' tab > Select 'MS OLE DB Provider for ODBC Sources' > In 'Use Data Source Name', select your DNS created in Step 2 and add any other parameters. At this point, you can test the connection and it should say 'Test Connection Succeeded'
Once you click 'OK', you should see the Connection String automatically generated. Mine was: 'Provider=MSDASQL;Persist Security Info=False;DSN=SQLiteTest'.
Follow the next few steps to import your data from SQLite.
You need something like this:
Provider=MSDASQL.1;Persist Security Info=False;Mode=ReadWrite;Initial Catalog=C:\XXX.db;DSN=SQLite3 Datasource
I am connecting to a Teradata database through ODBC with Stata on an Ubuntu server (12.04 LTS). Everything works fine, except that I have my TD userid and password stored in the .odbc.ini file, which seems like a terrible idea. The alternative is to enter them in Stata, which seems even worse and is awkward. Is there a way to do this more securely? The login info that I use to ssh into the server is synced with the TD database. It seems that it should be possible to pass that information along.
In ODBC terms you do not need to store usernames / passwords in any of your ODBC ini files. Both the ODBC SQLConnect and SQLDriverConnect support the passing in of username / password at the time they are called.
SQLDriverConnect would need something in your InConnectionString like "DSN=YourDataSourceName;UID=username;PWD=password".
You could go one step further and pass in the whole DSN as a command line argument thus meaning that you would not need an ODBC data source in an ini file. I'm sure one of the forum readers can post a sample for you from Teradata.
As for passing in the user name and password from your SSH loging. Your application would need to capture that and pass it to ODBC.
If you want to establish a finer grain of security around your odbc.ini file or other files on your Ubuntu server that may contain user credentials I would strongly suggest the use of Access Control Lists (ACLs). Beyond the typical Owner::Group::World permissions you can specify permissions down to the specific user on whether they are allowed or denied an explicit permission for a given file.
Other options regarding security on Teradata include the use of LDAP authentication if your environment supports it. Configuring LDAP on Teradata is beyond the scope of SO and in many cases a billable, professional services engagement with Teradata's Information Security CoE.
I have an ASP.NET app that uses a SQL Server database. I now need to pull data from Sybase ASE into that SQL Server database for my app to consume, and I'm not having any success with my ideas.
Has anyone done this? Any ideas/suggestions/tips?
You can configure a linked server from SQL Server to Sybase. It should be fairly vanilla using the Sybase provider on the MS side.
Okay, I've finally (through lame trial and error) found out how to link my Sybase ASE (12.5) server to my SQL Server (2008) which will allow the integration I want. Here's roughly how I did it:
Logged in to Sybase ASE OLE DB Configuration Manager (this is like the Sybase version of Windows' ODBC Data Sources) and added an OLE DB data source. I believe you must be an admin on the PC to do this.
In SQL Server 2008 Management Studio, went to Server Objects > Linked Servers. Right click and select "New Linked Server".
In the Linked Server Properties, I set the following properties:
General:
--Linked server: the name of your linked server as you want it to appear in your linked server list
--Provider: Select Sybase ASE OLE DB Provider from the dropdown list.
--Product name: The exact name of the OLD DB data source you just created in Sybase ASE OLE DB Configuration Manager.
--Data source: Same as Product name.
--Provider string: I left this blank
--Location: I left this blank
--Catalog: The default database (master or whatever) to log on to.
Security:
--You need to map a valid SQL Server logon to a valid Sybase logon. I did not use impersonation (which does a credentials pass-thru).
--I chose my connection Be made without using a security context.
Server Options:
--All the defaults worked for me.
Throughout, the standard SQL Server help worked fairly well as a guide. Though not always true, F1 was my friend here.
I can now do distributed queries, DTS or SSIS packages, and use SSRS. This takes a lot of the suck out of Sybase ASE.
Of course the above can be done via the command line using sp_linkserver, but the GUI is more comfortable for a lowly dev like me.
Use Management Studio or Enterprise Manager to import the data using the data importation wizard. That should be it, just make sure you pick the right data provider in the wizard and you should be good to go.
If you want this to be a live feed create a small windows service to manage the exchange of information. It should be relatively simple to do, just a little bit of leg work on your end. If you are adverse to that there are plenty of off the shelf solutions that can do this for you.
The question is a little vague on specifics:
Is this a one time conversion or part of a repeated process.
Is the source machine "reachable" from your destination machine (can you connect the two or do you need to read in files)
With most conversions there are two parts:
Physically getting data from the source into the destination.
Mapping data from the source to the destination tables.
It is hard to make any recommendations without more info. What would be fine for a one time conversion would not work if you need to read in data all day every day. Also, if the source database can not be connected to and you have to pass files, they methods change.