I am experiencing extremely slow connections to a local DB2 (v9.7 Express-C) database through ODBC on a Windows 7 system (x64). I wrote several test programs, each connecting to a local database for 100 times in a row (without querying) and measuring the time. Results are:
C++ x86 DB2/ODBC: 32bit C++ application, connecting to a local DB2 database via CDatabase
C++ x86 DB2/ODBC: same as above, but x64 application
PHP DB2/ODBC: Connecting to a local DB2 database via odbc_connect.
PHP MySQL/ODBC: Connecting to a local MySQL database via odbc_connect.
JDBC DB2: Java application, connecting to a local DB2 database using the DB2 JDBC driver.
JDBC MySQL: Java application, connecting to a local MySQL database using the MySQL JDBC driver.
My first thought was that something's wrong with my ODBC configuration, but as you can see connecting to a MySQL database through ODBC works like charm. On the other hand, connecting to DB2 with the JDBC driver instead of ODBC works fine too (although it's still a lot slower than MySQL).
I found this related question, but it does not apply to me.
Any hints on what might be causing this and how to resolve would be great!
Supplementary question: What are common connection times when connecting to a DB2 database through ODBC? Is it normal for the DB2 ODBC driver to be so slow?!
One thing that you should look at is the database activation. DB2 activates the database upon the first connection and deactivates it when the last connection is closed. During activation DB2 allocates transaction log files, memory pools, and performs a number of other tasks that take time.
This behaviour does not depend on the type of connection (ODBC or JDBC); the difference you observe might be explained by an extra connection that keeps the database active during your JDBC tests.
Try issuing ACTIVATE DB <YOURDB> before your tests, which will keep the database active even in the absence of connections. There is no way to activate databases by default, apart from issuing this command upon the system startup, e.g. from a batch file.
Related
Background: I have to transfer VS 2003 and VB6 applications from Windows 7 to a new Windows 10 Home machine. The applications are currently using DB2 9.7, Sql Server or Ms Access via ODBC. I decided to consolidate all dbs to DB2 on the W10 machine, using separate schemas for the different databases. The W10 machine is normally standalone (No Lan or Internet).
Details: I installed DB2 Express V10.5 and IBM Data Studio 4.1 on the W10 machine. DB2 Express gives me enough for my db needs, and I assume that Data Studio will give me similar GUI functionality as DB2 Control Center v9 on the W7 machine.
I installed DB2 and Data Studio under at least two different user ids(one being Db2admin), all with windows admin rights, and different credentials.
But every time I try to login/connect in Data Studio I'm rejected with SQ4499N, I must be doing something fundamentally Wrong.
when running the following commands from CMD I get the shown results.
db2val
DBI1379I The db2val command is running. This can take several minutes.
DBI1333I Installation file validation for the DB2 copy DB2COPY1
was successful.
DBI1339I The instance validation for the instance DB2 was
successful.
DBI1343I The db2val command completed successfully. For details, see
the log file C:\Users\User\DOCUME~1\DB2LOG\db2val-Wed Mar 02 16_28_37 2022.log.
DB2LEVEL returns:
DB21085I This instance or install (instance name, where applicable: "DB2")
uses "32" bits and DB2 code release "SQL10054" with level identifier
"0605010E".
Informational tokens are "DB2 v10.5.400.191", "s140813", "IP23617", and Fix
Pack "4".
Product is installed at "C:\PROGRA~2\IBM\SQLLIB" with DB2 Copy Name "DB2COPY1".
DB2Start returns:
SQL1026N The database manager is already active.
Switching to DB2 CLP
db2 => List Active Databases returns:
SQL1611W No data was returned by Database System Monitor.
db2 => List database directory returns:
SQL1057W The system database directory is empty. SQLSTATE=01606
db2 => list system odbc data sources returns:
DB21037W No data sources found.
Checking Google and stackoverflow didn't yield any suitable help, at least I didn't see it.
My experience is as app developer, not db2 admin except what is needed for app dev, and I had no problems with DB2 V9.7 on W7, but I'm lost what to do.
Any help is appreciated.
The prerequisites and expected behavior is described at the Configuring the IBM Data Studio client for remote operations link.
You got this error either because of misconfiguration or some DS bug / unexpected behavior.
The solution was to create the database manually and just to register this database in DS afterwards.
In practical terms: DB2 V10.5 SQL-Express failed to install the Sample Database. IBM Data Studio tried to connect to the Sample Database and failed the operation with SQL4499N. Manually creating a database overcame this problem.
I have been creating an access database for my assignment. I am using SQL Server 2014 for the datasource for the access tables. Now the problem is that according to the assignment
I need to make the db multiuser over network
it has to be an accde file
In short, how can I connect to SQL Server when I deploy the database on my college pc. And how to make the accde work on my school network where the SQL Server is not the one I am using at my personal machine.
It is a simple book entry database containing few tables including print button and picture of book attachment.
Use a DSN-less connection. Provide a function that changes the connection string on all linked tables.
See Linked table ms access 2010 change connection string
or Changing SQL connection information for DSN-less Access frontend
You don't want each user having to enter the server information into the frontend. So take your frontend to the school network, run the function to re-link all tables, then create the .accde, then distribute it.
If the sql server is on your same network, then all you have to do is link your tables to the production sql server. You then crate the accDE, and that can be deployed to any machine.
Access by “default” creates a DSN less connection. So if you follow the defaults when linking to sql server (use a FILE dsn), then once access links to those tables, access “converts” the DSN to a DSN less connection for you.
What this means is that you do not need any VBA re-linking code. When using a file dsn, access converts these to DSN less for you. Once linked, then Access ignores and does not use nor require the original DSN.
So your steps are:
Linking to the production SQL server on the network. Just make sure you use the “default” file dsn.
Once you are sure the accDB works with that production SQL server, you can then compile/create the accDE. That accde will now function on ANY workstation (and this work since access by default creates and uses and makes a DSN less connection for you).
You do NOT need any VBA re-link code.
You do NOT have to write some VBA code to create a DSN less connection (access does this automatic for you).
Of course, during this re-link process, your computer will have to be on the same network with the production SQL server you plan to link to.
If you were some off site worker, and you cannot be on the same network during the re-link process, then YES you would have to adopt some VBA code to re-link for you. However, if you can be on the same network during this re-link process, then at that point you can create the accDE file, and it can be distributed to any workstation on that network without further configuration.
About the only issue would be to ensure that you link to this production server using the standard and legacy “SQL Server Driver” as your linking choice. You can use the later “native 11” etc. drivers, but they are not installed by default on each version of windows and thus this ODBC driver may well not be installed on each workstation (but the standard SQL Driver is installed by default.
Again:
You do not need some VBA code or re-link code to create a DSN-less connection. Access by default when choosing a “file” DSN will create DSN-links for you – you thus don’t need any special re-link code, nor do you need some VBA re-link code to achieve DSN-less links.
I am using SQL CE 3.5 for one of my project, the front end is WPF application which process the given files and dumps the data to SQL CE database.
Presently application and DB is on same machine.
Client wants that he should be able to run the application from any machine on the network but database should remain on shared location of Server.
User will select the path to SDF file in the Application and then when any file is processed application will dump the data to database.
My question is, if keep SDF file on network shared location and access it from any machine then does it will work fine or could give problem?
actually, it is not possible - SQL CE does not support network-hosted operations: everything related to the sdf-file (temp data) is recorded to the local machine, not network source, thus server is unable to process requests correctly.
You can use SQL Express Server that acts like data storage, for the local client the only thing you need is Microsoft Synchronization library 2.1 (it also works with SQL CE 4.0 SP1)
Summarising, create the SQL CE database, fill it with tables, index them, then port it to SQL Server express, add sync module to your app (in a separate thread ofc) and that's it.
Another solution is to use MS Access DB, which allows such mess, but it is incredibly slow not to mention no way to allow simultaneous writing to the db.
I am aware of "SQL Server Profiler", But is there any tools or methods available to monitor the issued sql queries from the client machine?
Some of the things currently in my mind are:
1) The SysInternals ProcMon can log and tell when the executable process on client machine connects to sql server. Any similar but more advanced tools available to tell more data?
2) Any debug version or instrumented version of client libraries and APIs available for client machine to allow such operation?
You can enable ODBC Tracing from the ODBC Data Source Administrator (odbcad32.exe). The log file it generates is rather cryptic but it will provide you with the SQL statements run by the logged in user on that machine. There is also a checkbox labeled "Machine-Wide tracing for all user identities" for logging all SQL statements run by any user - including services - on that machine.
Logging may not start until you disconnect and reconnect to the SQL server. So, it is a good idea to restart whatever programs/services connect to your SQL Server. This is especially important if you have connection pooling enabled, which will keep connections open even if the program, in question, has disconnected.
Also, there are two versions of the ODBC Data Source Administrator on Windows 64bit, one for 32bit and the other for 64bit. So, you will need to enable logging for the appropriate bitness of the program you are tracing.
How To Generate an ODBC Trace with ODBC Data Source Administrator
Setting Tracing Options
Why my 32 bit applications cannot see the ODBC DSNs that I created on my 64 bit machine ?
ODBC Administrator tool displays both the 32-bit and the 64-bit user DSNs in a 64-bit version of Windows
Update: Another option for you would be to use a tool like Wireshark. Since it has the ability to sit at the network driver level, it can intercept all your network traffic - including but not limited to SQL. These are known as TDS packets - a standard that is used by Sybase SQL Server (ASE), Microsoft SQL Server and FreeTDS ( w/ UnixODBC).
RPR NA03: Analysing SQL Server performance using Wireshark and Excel
How do I filter SQL Server traffic between app and DB servers using Wireshark?
How can I decode SQL Server traffic with wireshark?
What does my SQL Server data look like over the wire?
Google Search for "Wireshark+SQL"
We recently moved a database from MS SQL Server 2000 to MS SQL Server 2008. Everything works as expected with our main .NET client application but we are having problems with a MS Access 2003 application which connects via ODBC. A System DSN is used to make the connection.
When the database was running on SQL Server 2000 the Access application would request a user name and password once when the program was first started. Now, with the database running on SQL Server 2008 a user name and password dialog is requested every time a different table is accessed I believe.
This behavior occurs when using either the user account we have used for years and it also occurs if I use the database system admin account ( I know this is bad practice, it was just a test. )
What do I need to reconfigure to return to the previous, desirable behavior where the user is only authenticated a single time?
You could look at using a "DSN-Less" connection to MS SQL, microsoft provide instructions here: http://support.microsoft.com/kb/892490
The relevant connection string can be found here: http://www.connectionstrings.com/sql-server-2008#p3
All this aside, JMK's question is important, the method above is for if you are having linked tables to the server present in your Access database, however when working with dedicated database server's I always advise using "ADO" connections rather than "DAO" as this will avail better performance (especially if you are running queries)
If it is just queries you need to run then consider either the ADO method or take a look at the "Pass through" queries option, this like ADO will have the server doing the work rather than the local machine and the performance will be greatly improved.