Does anyone have insight why one would use SnowflakeDbConnection (https://github.com/snowflakedb/snowflake-connector-net/blob/master/Snowflake.Data/Client/SnowflakeDbConnection.cs) instead of OdbcConnection other than the fact that you need ODBC driver installed on the machine? Are there other benefits to using the .net connector?
Are there other benefits to using the .net connector?
Besides not requiring to install, setup, and configure ODBC libraries and data sources, the .NET connector allows your application to be cross-platform, able to run anywhere .NET Core is available (Linux, macOS, etc.) in a self-contained manner.
Related
I am looking for a coding language that will work on Windows XP from a self contained executable that can connect to a MSSQL server.
it needs to be able to work without having to install any drivers or frameworks so all the .net based languages are out and i cannot figure out how to connect to MSSQL from C++ without .NET or installing a driver like ODBC.
any suggestions on what languages or libraries i could use to achieve this oddly specific task?
I'm using https://www.npmjs.org/package/odbc in an application targeting Windows.
Therefore it requires users to install Microsoft ODBC driver for SQL Server located here, which is a problem if the user doesn't have admin rights.
Any workaround?
You can use another system for databases, mongoDB, sqlite, etc. if your application is simply, i recommend sqlite
I am writing a Django application which needs to intereact with a SQLServer Database. I use the Django MSSQL Backend ADO.
I am trying to use it in a Linux machine (CentOS 6.4), but for the moment I am not able to establish the connection.
Anyone has suceeded on it or knows if it is possible to connect to django-mssql from a Linux environment?
Note: I've found this question but it is quite old. I am looking for an up-to-date answer.
Edit: The error I am receiving is the following. Remark that it is a Linux machine.
django.core.exceptions.ImproperlyConfigured: 'sqlserver_ado' isn't an available database backend.
Edit 2: PyWin32 is a requirement for the django-mssql package. But is possible any workaround for Linux?
Django-MSSQL only works on Windows, hence the pywin32 dependency (Actually, anything ADO is Windows dependent since it's built on Microsoft's ActiveX).
Try Django-SQLServer. It's based on Django-MSSQL but can pass info using python-tds which is not platform specific.
I will suggest to use django-pyodbc-azure instead of Django-MSSQL
Supports Django 2.0.3
Supports Microsoft SQL Server 2008/2008R2, 2012, 2014, 2016, 2017 and Azure SQL Database
Compatible with Micosoft ODBC Driver for SQL Server, SQL Server
Native Client, and FreeTDS ODBC drivers
What kind of support does LoadRunner have to loadtest a database. Is it possible to Connect directly to the jdbc "layer"?
Well, it depends upon the database.
LoadRunner supports connectivity with many native for SQL Server (Sybase and Microsoft variants), DB2, ORACLE and others.
IT supports ODBC.
Because of the JAva Virtual User type there is support for JDBC.
Because of the VB virtual user type there is support for OleDB type connectivity.
If you are looking at queues implemented in the database then you also have access to JMS via the web services virtual user or the Java Virtual User type.
Within Visual Studio you have the capability of building a DLL style virtual user for C/C++ or VB which leverages your application source code
Within Visual Studio and C# you can leverage the database connection options here for OleDB
For some types the interface can be recorded, for others it is hand coded or leveraging your source code. It might help to better understand the nature of the client you are trying to reproduce, what programmatic interfaces are leveraged by the client and what is the next upstream component in terms of vendor and version.
We are using Quest Geo Solution's Grid InQuest DLL (GIQ60.DLL) within an SQL Server Integration Services (SSIS) package. We have managed to use this without problems locally (32bit) by using tlbimp to create a .NET wrapper (interop). However, when this moved to our integration server this does not work as the server is 64bit.
The GIQ60.DLL is a 16bit DLL and the vendor has confirmed that they no longer actively support this. If we run the 32bit version of DTEXEC on the server , the package runs without problems. Is there a trick/way to convert the .NET wrapper to enable this to work SQL Server Integration Services (64bit install).
Alternatively , we need a replacement free 32bit .net library that will convert OS grid (Easting /Northings) into geospatial longitude/latitude for both UK and Ireland (they use different grid systems) then that would be a viable solution.
The only other solution i can think of is to create a windows service (32bit) that hosts your component and exposes it as WCF or Remoting end point. Then use script task in SSIS to access it. This way you can run your package in 64bit DTEXEC and your component in 32bit process.
HTH
In one environment I support, there is an SSIS package that relies on a certain version of a connection to Lotus Notes. That dll is a 32 bit dll and it doesn't work when executing in SSIS on the 64Bit production server.
We simple execute the SSIS package with a command prompt call to the 32Bit version of DTEXEC. That works fine.
You might try that to avoid having to maintain two different versions of code?