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.
Related
Currently, I have two separate SQL Server instances that I am querying using pass-through SQL queries via a form in Microsoft Access.
The queries to SERVER1 work every time without fail. I'd say about 80% of the time the queries to SERVER2 don't work after Access has been closed and re-opened until I go in and "modify" the OBDC connection string and save the query. I have quotes around modify because if I edit one character in the string and re-add it and then save, it usually starts to work again (but not always), even though the string hasn't changed. And once it works it will continue to work until once again Access is closed.
It's usually one of three errors, here are two of them and the third error which I get less frequently is that the login is incorrect:
The OBDC connection string is as follows (for what it's worth I also tried ODBC Driver 17 for SQL Server and got the same results):
ODBC;Description=SERVER2 PASSTHROUGH;DRIVER=ODBC Driver 11 for SQL Server;SERVER=SERVER2;UID=Test;PWD=Password;DATABASE=MyDB;LANGUAGE=us_english;ApplicationIntent=READONLY;
How do I go about solving this problem? Also, I am willing to provide any clarifying information.
Thanks!
Thanks to Alex for the reply.
Alex recommended going to SQLCMD Unable to complete login process due to delay in opening server connection. I should have been more scientific but I used a shotgun approach... I set my shared memory to disabled, as well as increased the connection timeout and command timeouts.
This then produced a new error for me similar to the one here No process is on the other end of the pipe (SQL Server 2012).
As many of the comments suggested, my SQL server was set to SQL Server and Windows Authentication mode, I changed it to Windows Authentication mode, and then back to SQL Server and Windows Authentication mode, and restarted my SQL server.
And for now, my problem has not shown up through multiple MS Access restarts and a few PC restarts as well for good measure. Fingers crossed.
I've been using Anylogic's feature to collect data to a database provided by the program.
However I have trouble extracting the data again. I've tried using the export to excel function, but the program is getting stuck (probably because of the large amount of data).
Now I'm looking at connecting directly to the database. Anylogic provides me with a connection string: jdbc:hsqldb:hsql://localhost:9001/nau_sterilcentral;file:C:\Users\nbn\Models\NAU sterilcentral\database\db
I only use the first part (until the file:C:\...) since DBeaver doesn't ask for more. My connection string i DBeaver looks like this: jdbc:hsqldb:hsql://localhost:9001/nau_sterilcentral
I expect the db to be running since i can query it from Anylogic, but I'm not sure. When I try to connect i keep getting an error:
connection exception: connection failure: java.io.EOFException
org.hsqldb.HsqlException: connection exception: connection failure: java.io.EOFException
I don't know AnyLogic, but:
HSQLDB needs to be started in server mode to allow a connection from a different process. If AnyLogic starts HSQLDB in embedded mode, you can't access the database as long as AnyLogic is running.
Also the JDBC URL needs to be either a server URL using localhost:9001 or a "local" URL containing a file name, you can not mix both things (and the syntax for the file based URL was wrong as well)
Assuming AnyLogic starts HSQLDB in embedded mode, you have to stop AnyLogic, then you can connect using a file based URL. The syntax for that would be:
jdbc:hsqldb:C:\Users\nbn\Models\NAU sterilcentral\database\db
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?
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 it possible to monitor what is happening to an Access MDB (ie. what SQL queries are being executed against it), in the same way as you would use SQL Profiler for the SQL Server?
I need logs of actual queries being called.
The answer depend on the technology used from the client which use MDB. There are different tracing settings which you can configure in HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Engines\ODBC http://office.microsoft.com/en-us/access/HP010321641033.aspx. If you use OLEDB to access MDB from SQL Server you can use DBCC TRACEON (see http://msdn.microsoft.com/en-us/library/ms187329.aspx). I can continue, but before all you should exactly define which interface you use to access MDB.
MDB is a file without any active components, so the tracing can makes not MDB itself, but the DB interface only.
UPDATED: Because use use DAO (Jet Engine) and OLE DB from VB I recommend you create JETSHOWPLAN regisry key with the "ON" value under HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\JET\4.0\Engines\Debug (Debug subkey you have to create). This key described for example in https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5064388.html, http://msdn.microsoft.com/en-us/library/aa188211%28office.10%29.aspx and corresponds to http://support.microsoft.com/kb/252883/en allow trace OLE DB queries. If this output will be not enough for you you can additionally use TraceSQLMode and TraceODBCAPI from HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Engines\ODBC. In my practice JETSHOWPLAN gives perfect information for me. See also SHOWPLAN commend.
UPDATED 2: For more recent version of Access (like Access 2007) use key like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Access Connectivity Engine\Engines. The tool ShowplanCapturer (see http://www.mosstools.de/index.php?option=com_content&view=article&id=54&Item%20%20id=57, to download http://www.mosstools.de/download/showplan_v9.zip also in english) can be also helpful for you.
If you're accessing it via ODBC, you can turn on ODBC logging. It will slow things down a lot, though. And it won't work for any other data interface.
Another thought is using Jet/ACE as a linked server in SQL Server, and then using SQL Profiler. But that's going to tell you the SQL that SQL Server processed, not what Jet/ACE processed. It may be sufficient for your purposes, but I don't think it would be a good diagnostic for Jet/ACE.
EDIT:
In a comment, the original poster has provided this rather crucial information:
The application I am trying to monitor
is compiled and at a customer's
premises. I am trying to monitor what
queries it is attempting against an
MDB. I cannot modify the application.
I am trying to do what SQL Profiler
would do for a SQL Server.
In that case, I think that you could do this:
rename the original MDB to something else.
use a SQL Server linked server to connect to the renamed MDB file.
create a new MDB with the name of the original MDB and link to the SQL Server with ODBC.
The result will be an MDB file that has the same tables in it as the original, but they are not local, but links to the SQL Server. In that case, all access will be going through the SQL Server and can be viewed with SQL Profiler.
I don't have a clue what this would do to performance, or if it would break any of the data retrieval in the original app. If that app uses table-type recordsets or SEEK, then, yes, it will break. But this is the only way I can see to get logging.
It shouldn't be surprising that there is no logging for Jet/ACE, given that there is no single server process managing access to the data store.
Keep in mind that the file sitting on your hard drive is simply a windows file. So, there is a big difference between a server based system and that of a simple text file, or Power Point file, or in this case a mdb file just sitting on the drive.
However you can get the jet engine to display its query optimizeing via showplan.
How to do this is explained here:
http://www.databasejournal.com/features/msaccess/article.php/3658041/Queries-On-Steroids--Part-IV.htm
The above article also shows how to access the jet disk read statistics, which I also find extremely useful for optimizing things.
Just remember to turn off that data engine logging system when you’re not using it as it creates huge log files…
you could write your own profiler, based on a "transaction" object that will centralize all instructions sent to the database, You'll end up somewhere with a "transaction.execute" method, and a transaction table in your access db. This table can then be used to collect transaction's instructions, start time, end time, user sending the instruction, etc.
I'd suggest upsizing the tables to SQL Server. There is a tool from the SQL Server group that is better than the Upsizing Wizard that is included with Access.
SQL Server Migration Assistant for Access (SSMA Access)
Also see my Random Thoughts on SQL Server Upsizing from Microsoft Access Tips page