I have an ODAC 32bits driver installed on my server, the 64 version doesnt work for me for whatever reason.
So i have to use this 32bit driver, which works just fine on my asp.net application... but now i cant use it to connect via sql server.
I need to make a shceduled task to extract data every day from an oracle database.
The idea here is make an SQL Job to extract said data. From my understanding i need a linkedserver to said Oracle database.
I have the linked server created, which is the following:
exec master.dbo.sp_MSset_oledb_prop 'ORAOLEDB.Oracle', N'AllowInProcess', 1
exec master.dbo.sp_MSset_oledb_prop 'ORAOLEDB.Oracle', N'DynamicParameters', 1
exec sp_addlinkedserver N'UT', 'Oracle', 'ORAOLEDB.Oracle', N'//xxx.xxx.xxx.xxx/', N'FetchSize=2000', ''
exec master.dbo.sp_serveroption #server=N'UT', #optname=N'rpc out', #optvalue=N'true'
exec sp_addlinkedsrvlogin #rmtsrvname='UT', #useself=N'FALSE', #rmtuser=N'xxxxxx', #rmtpassword='xxxxxx'
When it tries to connect it gives me the following error though:
El proveedor OLE DB de 32 bits "ORAOLEDB.Oracle" no se puede cargar en proceso en un servidor SQL Server de 64 bits.
Translated:
The OLE DB provider of 32 bits "ORAOLEDB.Oracle" can not be loaded on process in a SQL Server of 64 bits.
I dont know what to do from here, and im not even sure if this is the best solution for my needs either.
I dont have access to the external Oracle DB itself, only a connection string.
Any suggestions?
Try using the OPENROWSET function. This differs from using a linked server in that the connection is made on the fly - the command requires connection information to be included in the call. The command can be fairly complex, so see the BoL documentation on the function for full details.
Related
When we migrated from .NET framework to .NET core, we had to change the format of our iSeries connection string from using Server= to using Data source= and to include port#, but also we had to include Database= because without it the connection string could not be assigned to a connection due to an "Invalid argument" exception. With absolutely anything for a database, we always get a uniform error message:
ERROR [08004] [IBM] SQL30061N The database alias or database name \"QSYS \" was not found at the remote node.
(Notice extra spaces in the DB name)
No matter what we supply for a database, the error is always the same. We tried our actual library name similar to app0123 that is reported by DSPLIB or QSYS etc.
We also tried databases reported by DSPRDBDIRE named similarly to IHST0123 but in this case the error was different:
ERROR [42968] [IBM] SQL1598N An attempt to connect to the database server failed because of a licensing problem.
We know that there is no licensing problem with the server because it is our production environment that many applications in Java and C# connect to.
Our usual practice is that if an application App1 connects, it uses app1 user name and app01, app02 etc schemas, app01 being the default one. Therefore, we only ever had the iSeries host name like IHST01 etc in the connection string, and we added user ID and password through the connection string builder.
We are having no issues connecting through .NET core connector to DB2 LUW since database on it is very apparent and unambiguous. Since we never had to specify an iSeries database under .NET framework, it is not clear what it has to be. Does anybody know?
The library (aka schema) name is not the database name.
The *LOCAL entry in DSPRDBDIRE should be your DB name.
A better tool is IBM Access Client Soultions (ACS) "Database -->Schemas" tool which has a UI like so:
On the connected server (ut29p63.rch.stglabs.ibm.com), there are (at least) two databases:
ut29p63
Dbtest
I'm surprised you don't think the DB name was needed for .NET Framework or Java as I've always needed them. If you've only got one database on your IBM i, as is common for smaller boxes, it's possible the DB name matches the system name.
Judging from the license error message, you are getting connected.
However, the .NET Core nuget packages use the IBM Db2 Connect driver. This driver is included for Db2 for LUW, and with an appropriate and optional license allows connecting to IBM Db2 for i or IBM Db2 for z/OS.
In other words, the Db2 Connect driver can always connect to Db2 LUW but you'll have to pay for an enhanced license to connect to IBM i or IBM z/OS. See IBM Db2 Connect License Types You'll need an Enterprise license or an Unlimited Edition for System i.
If you were using Db2 Connect driver for your .NET Framework, the same license will work for .NET Core (assuming the Db2 Connect versions match).
However, if you were using the free ODBC/OLEDB/ADO driver for .NET Framework, then you'll need the Db2 Connect license for .NET Core.
I am trying to set up an .accdb as a datasource on the reporting server. The database is local on the server and I have followed all the instructions to create a 32 bit and a 64 bit ODBC connection for .mdb and .accdb. I set up the data source on the Report Manager site as ODBC with dsn=dbname and test the connection and it is successful.
From the Report Manager site, I open a report in Report Builder. I add a dataset and point to the shared connection. Test connection is successful.
I create a new data set based on this data source and click Query Designer and get this error: Unable to Connect to Datasource dbname. ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application.
Then I prompted for credentials. Of course nothing works there. And this particular .accdb has only Admin with no password anyway. All users can access it.
The error makes me think there's a 32 bit vs 64 bit conflict. The .accdb is 32 bit, but Report Manager only sees it with the 64 bit connection, then tanks when I try to create the data set.
I've set the same odbc connections up on my local machine and on the server. Still no dice. Any and all help would be appreciated.
I kept working on this and was able to create a data source with the following connection string:
Driver={Microsoft Access Driver (*.mdb, *.accdb)};Dbq=\server\path\database.accdb;Uid=Admin;Pwd=;
I edited the report and used query builder to test the query and results. Query builder allows me to see results. Yay! Progress!
But now when I preview/run the report I get the following:
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'dataset1'. (rsErrorExecutingCommand)
For more information about this error navigate to the report server on the local server machine, or enable remote errors.
Any ideas?
I was able to make this work. I had to install the 32 and 64 bit drivers on both the reporting server and the local (editing) machine. I created identical DSNs (32 bit and 64 bit) on each machine. Then set up the datasource with an OLE DB connection string.
Once complete, I was able to write reports against the database (but not browse tables). Other users could access the report from their own machines without the ODBC connections or drivers installed.
We'll call this a win. On to the next problem.
I'm trying to connect to a SQL Server 2016 database in RStudio. I'm using RStudio on my laptop. I could remote in to the server and install RStudio there if it were absolutely necessary, but working locally has massive advantages so I would really prefer that if it were possible. Connection with the server goes through a VPN (FortiClient) that I have running on my laptop.
On this server, there are two SQL Server instances. One is a SQL Server 2012 edition, which is the default instance and hence not named - it used to be the only instance on this server. The other one is the 2016 edition. This instance was set up more recently in order to use the R integration capabilities new to SQL Server 2016. Because the server already had a default instance, this instance had to be named and it hence is called DEVR.
When I access the instances in SSMS and click 'Properties', the name of the default instance is DWH-ACC and the 2016 instance is called DWH-ACC\DEVR.
This is the code I'm running in RStudio to test my connection:
server <- "[IP-ADDRESS]\\DWH-ACC\\DEVR"
databaseName <- "Database"
user <- "user"
pwd <- "password"
sqlShareDir <- "C:\\Dir"
sqlWait <- TRUE
sqlConsoleOutput <- FALSE
sampleDataQuery <- "SELECT TOP 10 FROM [dbo].[Table]"
cc <- RxInSqlServer(server = server, databaseName = databaseName, user = user, password = pwd, shareDir = sqlShareDir, wait = sqlWait, consoleOutput = sqlConsoleOutput)
rxSetComputeContext(cc)
inDataSource <- RxSqlServerData(sqlQuery = sampleDataQuery, server=server, databaseName=databaseName, user=user, password=pwd, stringsAsFactors=TRUE, rowsPerRead=500)
rxGetVarInfo(data = inDataSource)
I've tried several options for the server specification, among which [IP-ADDRESS]\\DEVR and [IP-ADDRESS]/DEVR, which both do not work either. This is the error I get when I run the code:
[Microsoft][ODBC SQL Server Driver][DBNETLIB]The SQL-Server does not exist or permission has been denied.
Could not open data source.
ODBC Error in SQLDisconnect
(Message translated from Dutch, by the way - this may not be the exact error text in the English version of the software)
When I try simply the IP address as my server connection string, I get a different error that seems to indicate it is able to find the instance (the 2012 one, i.e. the wrong one) but not able to process the query.
[Microsoft][ODBC-stuurprogrammabeheer] Fout in functievolgorde
I'm not sure how to translate this one, but it seems to be related to ODBC-drivers and says "error in function order". Anyway, this error is unrelated and I don't need it solved or explained, it simply goes to show that R does seem to be able to connect to the default instance but not to the newer, named one.
Enable Implied Authentication for Launchpad Accounts
Specifically navigate to the User Account from the Control Panel and you'll see the SQLR UserGroup with 20 accounts.
Permission these on the Server and DB Table with write access.
That should see you right. Good luck
You could create a ODBC connection in your local instance. A tutorial on creating ODBC connections can be found here. Background about the different types of SQL Server ODBC connections can be found here.
The ODBC connection should be able to distinguish between the the different SQL Server instances.
For me the main advantage in using ODBC connections is that I don't have to store database passwords inside/near my R scripts.
In R/Rstudio you can connect to the SQL Server instance via the ODBC channel. A tutorial on ODBC channels and RevoScaleR: link.
Other packages in R also provide possibilities to connect to ODBC connections, for instance: RODBC, dplyr.
I have an asp page which brings data from DB through ODBC connection, but it's failing. The stored proc is defined in the asp page which brings the data, SP seems to be fine but data is not coming.
Post the error, blur your passwords (hope that box isn't exposed.)
Your error is likely a missing ODBC driver. Check whether your sites AppPool is running 32 bit or 64 bit, then check the respective ODBC Manager to see if the driver you are using exists on the machine. If not go download one for whatever database server you are using and install it.
If you have windows 8+ or 2012 Server + on the server, just use the start screen search to find the ODBC managers, can't remember their run commands, and their difficult to find in the UI, I don't even remember where they are.
This commonly happens when people switch their app pool from 32 bit to 64 bit in a server upgrade, or just to run 64 bit. There are two versions of ODBC drivers, one 32 and one 64 bit. If you don't have the 64 bit ODBC driver and switch the app pool to 64 bit, your DB access will time out or fail. ASP commonly has "On Error Resume Next" all over the place, so might be eating the error and showing something generic instead.
I have sorted out this issue.Commented out the ODBC section and created a new SQL connection string directly in the asp page-
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open strConn
"Provider=SQLOLEDB;Server=SERVER\INSTANCE;Database=DBName;UID=*;PWD="
I'm working on some issues with psqlODBC's XA/MSDTC transaction handling and I find myself needing to obtain the server connection details (hostname, port, etc) from any user-supplied dsn programmatically without having psqlODBC invoked via the Driver Manager to do so.
Just parsed key/value string pairs will do; the problem is resolving user/system/file DSNs to get the underlying connection info.
The underlying issue I'm trying to solve is that a 32-bit application using MSDTC on a 64-bit system will supply a DSN that works for the 32-bit PostgreSQL driver. The 64-bit PostgreSQL drivers have different names - PostgresSQL ANSI vs PostgreSQL ANSI(x64) and similar for the Unicode drivers. So a DSN that works for a 32-bit app won't work for 64-bit apps ... like msdtc.exe. So I need a way to get the connection parameters the 32-bit app used and feed them into the 64-bit ODBC driver (or direct to libpq).
In the case of a DSN-less connection string like:
DRIVER={{PostgreSQL ANSI}};SERVER=127.0.0.1;PORT=5432;DATABASE=SOMEDB;UID=Administrator;PWD=;CA=disable"
I could just parse it to get the relevant info, but that won't work for file, system, or user DSNs where the XA transaction co-ordinator used by MSDTC only gets whatever the original user app passed to the ODBC layer - like:
DSN=SomeUserOrSystemDSNName
or
FILEDSN=C:\SomeFileDSN.dsn
and wrapped in that DSN is a DRIVER={{{PostgreSQL ANSI}}.
I've taken a look at the ODBC API docs and I don't see anything that seems to expose a way to load any DSN string, resolve file/system/user DSNs and get a parameter hash/map. OTOH, there's a lot of documentation out there, and some of the sections and function names aren't what I'd call predictable.
So - please tell me I'm missing something obvious, and there's a way to just:
GetDSNProperty("FILEDSN=C:\SomeFileDSN.dsn", "SERVER");
.. rather than writing hacky code to manually look up each DSN type.