My application (a testcase automation tool) does not support calling ODBC's SQLSetStatmentOption. I need to set the cursor option SQL_SOPT_SS_CURSOR_OPTIONS to SQL_CO_FFO_AF. Right now I connect to the server using a connection string (no DSN). I am using sqlsrv32.dll or Sqlncl10.dll.
Is there a way to set the cursor option in a DSN (or other layer) between my tool and the MSSQL server? The tool handles creating the cursor (or results set) and iterating through the result set in a way that seems to obscure any ability to manage it directly. It does allow for calling SQLSetConnectAttr() but as far as I can tell there's no way to set a cursor option in there.
All of this is an attempt to speed up retrieving data over a remote connection. In SQL Management Studio I get comparable response times to the local or remote DB, but in the automation tool the remote queries take hundreds of times longer, probably because it seems to be making a round trip to the sever for every row.
There is no way to set statement options in the connection string that I know of. In ODBC 1.0 and 2.0 you could make calls to SQLSetConnectOption for statement attributes and they set those attributes in each statement created in that connection but a) that is an old version of the API (although it probably still works) b) you still cannot do it from the DSN. In unixODBC you can set some environment and connection attributes in the DSN but your obviously Windows.
I'm not convinced anyway that you've identified the problem correctly and even if you have, how do you know your app does not use SQLGetData (which is disabled when you set SQL_CO_FFO_AF). Are you sure you've not enabled MARs. Did you try getting an ODBC trace to see what the app is doing?
Related
In Hitachi Pentaho 8.2 Data Integration (Spoon) we are trying to configure "MultisubnetFailover=True" for a SQL Server database connection.
For database connections we are using "MS-SQL Server(Native)/Native JDBC". The problem is that I can't find where to set this property in the Database Connection component, and it doesn't look like I can specify the complete connection string for the driver to use. Where can I set this property?
It doesn't look like the Options tab is the correct place for setting this property, and I don't see a way to just specify the entire connection string myself. Also, ODBC can't work for us because the ETL changes the server and database dynamically (we use Pentaho variables to vary those) and ODBC is only one hardcoded connection.
Any help will be appreciate it.
Using the following:
MS Access 2016, Office 365
SQL Server 2012
I have 100+ SQL Server tables and views linked into an Access database via ODBC connection. All of these SQL Server objects are from two SQL Server databases that reside on the same server. All of these connections have been set up using the Access user interface and re-linked via the Linked Table Manager.
I've been experiencing a number of Access database issues lately, so I’m combing through everything with a fine-tooth comb. I noticed that the connection strings for all my SQL Server objects have a number of inconsistencies (see below). There does not seem to be any pattern in terms of when these objects where created and the format of the connection string either.
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1;Network=DBMSSOCN
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database1
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database2
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database2
Is it problematic that there are so many variations of the connection string? I've done some research (i.e., Googling), but I don’t much experience in this area of databases. Some connections have a "Network" specified, but others don’t. Per connectionstrings.com (https://www.connectionstrings.com/define-sql-server-network-protocol/), “Network=DBMSSOC” specifies a Winsock TCP/IP connection, which I believe is the appropriate choice for my network setup. Is it problematic that this parameter is excluded from several of the connection strings?
I would most certainly “harmonize” all of the linked tables to the same connection.
You can use the linked table manager to do this, but likely code is better.
You need to select all tables in the linked table manager, and MAKE sure you click on prompt for new location. This will force you to create (or select) an existing DSN. In fact, I would select all tables from the “one” given database, and then click on the “always” prompt for new location. When you do this, then all will posies the SAME link and connection string.
There are good number of reasons, one good reason is Access will cache the connection for you. So if you have “different” connections for the same database, you will have multiple caches of those connections. This likely will not affect performance “much”, but it still a good idea.
And if you are NOT using a trusted connection, then your connection strings in fact do NOT need to include the uid/password. (However, the cache of the uid/password requires exact string matches (minus the uid/password). In this approach, you can execute a “one time” logon on application start up, and then all linked tables (without the uid/password) will now work. However, you using trusted connections here, so this tip + issue don’t matter.
In your example, you using trusted connections, so issues are “much” less of a worry or problem.
I also STRONG suggest that when you launch the ODBC manager from Access, that you ALWAYS but ALWAYS use a FILE dsn. The reason for this is that then Access will convert the connections to DSN-less for you.
This means that you can now deploy the front end application to any workstation, and you don’t need to setup or have any DSN connection copied, or even setup on the workstation.
So I would in fact select all of the tables for one given database, (check the prompt for new location), and then create a FILE dsn (they are the default anyway). Once you link, then do the same for all the other tables that point to the other database. Again re-link.
The result will be a dsn-less connection, and thus your application will work on any workstation on the network, and do so without having to setup a dsn of any kind on each workstation.
So yes, you don’t have to, but it seems over time, some tables were linked using a different DSN, they should be harmonized. And if you ever introduce some automatic linking code, you want to be able to distinguish between the two databases, and you code will have a rather difficult time doing this with a “hodge” podge of differing connections.
So you can use the linked table manger to harmonizing the connections – just ensure you select all tables from a single given database, and then re-link with a FILE dsn, the result will be a DSN less connection (access will ONLY use the DSN during the linking process – after that, access don’t care, nor does it use or even look at the DSN, or even if it exists.
Having said all of the above, it not clear if this issue is related to your errors, or instabilities in your application. (a good idea is to always distribute a compiled version of your application - (a accDE as opposed to accDB).
I am trying to dump the whole data from the developer db server to my local machine using SQL Developer, but whenever I try to export, the connection gets halted before I finish dumping/exporting.
Is there a way to adjust that db connection timeout?
There is no connection time limit imposed by SQL Developer. If your connection is getting lost, that implies either that there is something in the network (a firewall for example) that limits the length of a connection or that there is something configured in the database (a profile, Resource Manager, etc.) that is causing the connection to be terminated. Since you haven't told us what error you get, it is impossible to guess which of these options is the most likely source of your problem.
Of course, it would probably be more effective to use the proper tools (the DataPump version of the export and import utilities) for this sort of thing.
I need to connect and send/receive information from an MS SQL server in my Lotus Notes app using #formula in realtime (I can connect using an agent, but I need to use inline code for this).
The commands themselves seem pretty straight forward, but setting up the configurations seems to be a topic with scarce documentation. Apparently I need to install an ODBC driver. Where would I find that, and do I install that onto the server or onto the workstations that will run this app?
If any Lotus gurus could step me through setting this up, it would be greatly appreciated.
Thanks
You'll need to install the ODBC driver on the workstations that run this app, if the users will be triggering the ODBC connections. If at all possible, I highly suggest setting this up on the server side, and having it run via an agent. That'll save you from a few headaches, including having to maintain the ODBC connections on each workstation and worrying if each workstation has access to the data and server.
You first just want to make sure your ODBC setup is correct. You'll need the appropriate driver, of course, and the connection information. This site has a walkthrough to give you an idea of how to setup an ODBC database connection
If you have MS Access you can use it to test querying from the ODBC data source. Once you've tested the connection works, you'll just refer to the data source name (DSN) in your #DbColumn, #DbLookup, or #DbCommand formulas.
Back to my suggestion on setting this up on the server side, that would mean you'd keep a copy of the data you're querying within the Notes database itself, and then users would be interacting with read-only data in Notes. You could schedule updates regularly on the server side of that read-only data and effectively create a cache of the data in your Notes environment. Then that data would replicate around to other replicas of the database, but remove the trouble of the ODBC connection being needed everywhere.
If you need realtime data, though, that solution is out the window and you'll have to go with a local solution. In that case, you might want to look at the LCConnection class or using an ADODB.Connection from script, as both will allow you to create DSN-less connections to data sources. You'd then save the trouble of requiring ODBC data sources on each workstation, and only have to worry about whether they can access the server from their workstation.
I would add another option to Ken's list. It involves having the server do the queries of the external database (therefore you are only setting up ODBC in on the server - you don't have to deal with it on the workstations). You create an agent that is launched on the server using the 'run on server' technique. When the workstation needs to query the external data, the code creates a throw-away document in the database, puts the query criteria into the temporary document, saves the document, then calls the 'run on server' agent passing a reference to the temporary document. The server launches the agent, reads the criteria from the temporary document, does the query, and writes the results back to the temporary document. Then the workstation can access the query results from the temporary document. A scheduled agent can delete the temp docs on a regular basis.
It sounds complicated, and it all has to be done in script, but I've done this in many applications and it is fast, flexible, easy to administer, and gives your applications a lot of power. Note that end users must have the ACL rights to create a document in the db (the temp doc) in order for this to work.
Good luck!
Is there a tool for windows that we can use to inspect any SQL commands that go through a particular ODBC data source?
You can make ODBC log out everything it's doing:
http://support.microsoft.com/kb/274551
http://msdn.microsoft.com/en-us/library/ms711020%28VS.85%29.aspx
You can also do it programmatically:
... One can do this by calling SQLSetConnectAttr and set the SQL_ATTR_TRACE attribute in the connection to SQL_OPT_TRACE_ON. So, by doing this you would be enabling/disabling it for the connection duration.
http://decipherinfosys.wordpress.com/2009/01/17/odbc-tracing/
If you're using SQL Server, look at the SQL Server Profiler. Profiler allows you to monitor/trace all communications between your application and the SQL Server, including which procedures are called, parameter values, etc, without having to modify your application.
If you're using a different server, you should be able to find a sql proxy that will do the same thing.