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.
Related
I get the following error when I try to connect to SQL Server directly with a C++Builder 10.2 Tokyo application. I couldn't locate the library requested despite all my searching.
Can anyone help? I'm at a crossroad to decide to continue with C++Builder or Xamarin.
Do you have C++ Builder Enterprise or Architect edition? You need this to connect to SQL Server using FireDAC. C++ Builder Professional edition can only connect to local databases.
Looking at this page:
Embarcadero Microsoft SQL interface
suggests to me that Microsoft SQL with Android client is not supported.
FDConnection is FMX compatible, but the drivers for various OSes are not.
There's a company called Devart that develops direct access connectivity for RAD studio mobile devices; Not sure if this will work if you only have C++ builder; but worth a try;
I'm currently in the same pickle and I'm busy writing a tcpclient/server proxy fmx app that will run on a windows server[where the mssql driver will work]
The idea is to connect from mobile device with tcp client to tcp server component running on windows and have that app grab the info i need for mobile app. Not the fastest solution in long run as you have to do all your authentication and encryption yourself and not the cheapest either as it requires an online windows server or pc... but if you already have it, you might as well use it.
Will update if it succeeds or fails
When writing an application that'll work with MS SQL database all we do is just we specify the connection parameters (either hard coded or dynamically). And when we install that application on a machine, we don't care if that machine has the proper tool to make the connection to the MS SQL Server database available.
However, in Oracle things are different. We have to make sure that all the machines that we want to install the app has Oracle Client set up. It will not work otherwise. Now my first question is what advantage does this provide? And the second one is if there's some way to achieve the similar in SQL Server?
Realistically, if Oracle owned Windows, the Oracle client would be installed with Windows and the SQL Server client would be a separate install. It's not a matter of advantages and disadvantages, it's a matter of who owns the stack and can bundle their software with the operating system.
Depending on exactly how you are building your Oracle application, there is a good chance that you can use the Oracle Instant Client or the Oracle thin (type 4) JDBC driver to provide connectivity to the database. Either of these can be installed by your application without requiring a separate Oracle client install.
What is the difference between SQL Server Native Client connection and ODBC connection? What are the pros and cons of these two?
Huh? ODBC is officially dead? Someone might want to let Microsoft know that:
Microsoft is Aligning with ODBC for Native Relational Data Access
From the above link:
ODBC is the de-facto industry standard for native relational data access...
and
The commercial release of Microsoft SQL Server, codename 'Denali' will be the last release to support OLE DB.
and finally,
"We encourage you to adopt ODBC in the development of your new and future versions of your application. You don’t need to change your existing applications using OLE DB, as they will continue to be supported on Denali throughout its lifecycle. While this gives you a large window of opportunity for changing your applications before the deprecation goes into effect, you may want to consider migrating those applications to ODBC as a part of your future roadmap. Microsoft is fully committed to making this transition as smooth and easy as possible.""
(emphasis added)
ODBC is useful for times when the underlying database might change but you don't want your code to (assuming the SQL stays the same across technologies). You could connect to an Oracle database one day and switch out to a SQL server database the next. The disadvantage is that you don't get the optimizations that having specific drivers affords you. The SQL Server Native client driver has been proven to be much faster than just using a standard ODBC driver.
What is the difference between SQL Server Native Client connection and ODBC connection?
ODBC is a standardized API.
ODBC drivers are shared libraries that use native protocols (like SQL Server shared memory, or SQL Server TCP/IP) to implement the ODBC interface.
In other words, ODBC is an abstraction that enables code to work against multiple database technologies.
It's similar to Java's JDBC, or Python's DB-API, or GO's database/sql, except ODBC drivers use C functions. Also, they are more frequently installed at a system level.
ODBC has the usual pros and cons of any abstraction.
Pros: Makes code more flexible/portable.
Cons: Adds performance overhead and has fewer features.
It sounds like you know that you will use SQL Server and will always use SQL Server.
In that case, I'd use a native client library if it's available.
SQL Server Native Client is a single dynamic-link library (DLL) containing both the SQL OLE DB provider and SQL ODBC driver for Windows.
SNAC 11 is a single dynamic-link library (DLL) containing both the SQL
OLE DB provider and SQL ODBC driver for Windows. It contains run-time
support for applications using native-code APIs (ODBC, OLE DB and ADO)
to connect to Microsoft SQL Server 2005, 2008, 2008 R2, and SQL Server
2012. A separate SQL ODBC-only driver is available for Linux.
https://blogs.msdn.microsoft.com/sqlreleaseservices/snac-lifecycle-explained/
is it possible to import a MS access database (.mdb) in a seam project using JBoss tools within Eclipse (Ganymede)?
Starting a new seam project, I cannot see any field which uses ms access as database type.
Any answer is appreciated.
Java programs generally talk to databases through JDBC drivers. To my knowledge there is no JDBC driver for Access MDB files. You can use the JDBC-ODBC bridge to create a connection to the Access database with a little help from the Access ODBC driver. How to set up this construction is explained here
You have to create a database connection in the JBoss application server that uses that connection, how this is done can be found here.
I understand that some databases have native support in R (e.g. MySQL) but you can connect to other DBs like MS SQL Server using RODBC. How much speed improvement does one gain for reading/writing with the native drivers vs. RODBC? What other DBs have native drivers in R? Is reading faster or slower than writing generally?
If you're specifically interested in SQL Server, the reference below is a little bit out of date but I imagine it probably still holds.
Using ODBC with Microsoft SQL Server
Performance of ODBC as a Native API
One of the persistent rumors about ODBC is that it is inherently slower than a native DBMS API. This reasoning is based on the assumption that ODBC drivers must be implemented as an extra layer over a native DBMS API, translating the ODBC statements coming from the application into the native DBMS API functions and SQL syntax. This translation effort adds extra processing compared with having the application call directly to the native API. This assumption is true for some ODBC drivers implemented over a native DBMS API, but the Microsoft SQL Server ODBC driver is not implemented this way.
The Microsoft SQL Server ODBC driver is a functional replacement of DB-Library. The SQL Server ODBC driver works with the underlying Net-Libraries in exactly the same manner as the DB-Library DLL. The Microsoft SQL Server ODBC driver has no dependence on the DB-Library DLL, and the driver will function correctly if DB-Library is not even present on the client.
Microsoft's testing has shown that the performance of ODBC-based and DB-Library–based SQL Server applications is roughly equal.
It's an empirical question, so why don't measure it for the combination you are interested in?
Public code is not hidden, so why don't you count what other DB interfaces CRAN has? For DBI alone, we have SQLite, MySQL, Postgresql, Oracle; for custom db backends there are things like Vhayu.
Specialised forums exist, so why don't you ask on r-sig-db?
Lastly, as soon as there is an API and a need people tend to combine the two. I have written two different (at-work and hence unreleased) packages to two highly specialised and fast backends.