Is there a way to define the calling 'program name' when using the Iseries ODBC driver? When I run a command against our AS400 using the Iseries Access ODBC driver, the calling program in the call stack of the as400 shows the program name as blank. I'd like to define one because we have a trigger that needs to know who is the caller.
The ODBC connection is proxied through a QZDASOINIT job. I don't believe there is a way to identify the specific connection (or program) that fired the trigger.
As JamesA points out, all ODBC requests go through the QZDASOINIT job, so you can't change the call stack to determine the caller.
To get around this problem, DB2 for i includes client special registers that are automatically set by the ODBC driver (which you can override if you wish) and your trigger can then use. For more information see: http://ibmsystemsmag.blogs.com/i_can/2009/10/i-can-use-client-special-registers.html
It's been possible for some time, exposed only since i 6.1. For an example usage, run this statement in i Nav 'Run SQL Scripts...':
select CURRENT CLIENT_APPLNAME, CURRENT CLIENT_PROGRAMID, CURRENT CLIENT_WRKSTNNAME from sysibm.sysdummy1
Support is available to application developers using a JDBC, OLE DB, CLI, or .NET data provider. They can also be set by calling a special stored procedure.
Using IBMDASQL for example, a connection string might include:
conn.Open "Provider=IBMDASQL; Data Source=MyAS400;" & _
"Client User ID=MYWINUSRID; Client WorkStation Name=MYWINPC; " & _
"Client Program ID=somepc.exe; Application Name=Sample for Audit"
The SQL Reference discusses new "special registers".
Related
I am trying to determine the application that is using a specific session ID in an Oracle 11g database. I can find the service name of the session id using this query
select SID, SERVICE_NAME
from v$session
where SID = <sessionID here>;
Unfortunately, several applications use this service name to connect to the database. Is there another table/query that I can use to determine which application is using this session ID?
There are other columns in V$SESSION that might be useful, e.g.:
select username, osuser, logon_time, status, program, module, client_identifier, client_info
from gv$session
where sid = <sessionID here>;
However it is up to your application to set or override the last four values.
For example, a session started from SQL*Plus shows program as something like sqlplus#client_host (TNS V1-V3) and module as SQL*Plus. SQL Developer shows both values as that name. A JDBC connection will have something like 'JDBC Thin Client' for both by default, but the application can override those and/or set client_identifier and client_info if it chooses to. As can a Pro*C application, which defaults to both program and module looking something like exe_name#client_host (TNS V1-V3).
As SQL Developer is using JDBC, that is overriding both program and module with it's own value; and SQL*Plus is overriding the default module value.
So if the application using the session ID you're interested in has configured any of those values you should get a pretty good idea of what it is. And if it hasn't then you may still get clues about the kind of application (e.g. JDBC). The osuser might be useful too.
See SYS_CONTEXT and the DBMS_APPLICATION_INFO and DBMS_SESSION packages for more about how an application can set those values.
I am working on a migration project where we are migrating one application from Weblogic to Websphere 8.5 server.
In Weblogic server, we can specify default schema while creating datasource but I don't see same option in WebSpehere 8.5 server.
Is there any custom property through which we can set it , I tried currentSchema=MySchema but it did not work.
This answer requires significantly more work, but I'm including it because it's the designed solution to customize pretty much anything about a connection, including the schema. WebSphere Application Sever allows you to provide/extend a DataStoreHelper.
Knowledge Center document on providing a custom DataStoreHelper
In this case, you can extend com.ibm.websphere.rsadapter.Oracle11gDataStoreHelper.
JavaDoc for Oracle11gDataStoreHelper
The following methods will be of interest:
doConnectionSetup, which performs one-time initialization on a connection when it is first created
doConnectionCleanup, which resets connection state before returning it to the connection pool.
When you override doConnectionSetup, you are supplied with the newly created connection, upon which you can do,
super.doConnectionSetup(connection);
Statement stmt = connection.createStatement();
try {
stmt.execute(sqlToUpdateSchema);
} finally {
stmt.close();
}
doConnectionCleanup lets you account for the possibility that application code that is using the connection might switch the schema to something else. doConnectionCleanup gives you the opportunity to reset it. Again, you are supplied with a connection, upon which you can do,
super.doConnectionCleanup(connection);
Statement stmt = connection.createStatement();
try {
stmt.execute(sqlToUpdateSchema);
} finally {
stmt.close();
}
Note that in both cases, invoking the corresponding super class method is important to ensure you don't wipe out the database-specific initialization/cleanup code that WebSphere Application Server has built in based on the database.
As far as I know Weblogic only allows setting a default schema by setting the 'Init SQLto a SQL string which sets the current schema in the database, such asSQL ALTER SESSION SET CURRENT_SCHEMA=MySchema`. So, this answer is assuming the only way to set the current schema of a data source is via SQL.
In WebSphere, the closest thing to WebLogic's Init SQL is the preTestSQLString property on WebSphere.
The idea of the preTestSQLString property is that WebSphere will execute a very simple SQL statement to verify that you can connect to your database properly when the server is starting. Typically values for this property are really basic things like select 1 from dual', but since you can put in whatever SQL you want, you could setpreTestSQLStringtoSQL ALTER SESSION SET CURRENT_SCHEMA=MySchema`.
Steps from the WebSphere documentation (link):
In the administrative console, click Resources > JDBC providers.
Select a provider and click Data Sources under Additional properties.
Select a data source and click WebSphere Application Server data source properties under Additional properties.
Select the PreTest Connections check box.
Type a value for the PreTest Connection Retry Interval, which is measured in seconds. This property determines the frequency with which a new connection request is made after a pretest operation fails.
Type a valid SQL statement for the PreTest SQL String. Use a reliable SQL command, with minimal performance impact; this statement is processed each time a connection is obtained from the free pool.
For example, "select 1 from dual" in oracle or "SQL select 1" in SQL Server.
Universal Connection Pool (UCP) is a Java connection pool and the whitepaper "UCP with Webshere" shows how to set up UCP as a datasource.
for JDBC datasource, the steps are similar but, you can choose the default JDBC driver option.
Check out the paper for reference.
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
I have Oracle 10g and have installed ODBC via the instant client. I am able to use the ODBC administrator and set up a DSN and test successfully, and whenever I use Microsoft Access I can connect to my database no problem. I can also use Visual Web Developer to traverse the data.
But, when I try and use Classic ASP with:
myConn.Open "DSN=oracle10g;" & _
"Uid=myOracleUsername;" & "Pwd=myOraclePassword"
I get:
-2147467259Specified driver could not be loaded due to system error 5 (Oracle in instantclient10_2).
An error occurred while trying to create Server Object.
I have searched various places but nothing seems to work. All ORACLE_HOME, TNSnames, IUSR_X security, all is correct. I am thinking it is a DSN connection string problem.
Anyone know?
Try using the following DSN-less connection string:
myConn.Open "Provider=MSDAORA;Data Source=instance_name;User ID=myOracleUsername;Password=myOraclePassword"
I've used this exact connection string for older version of Oracle client, but can't see any reason why it won't work for your version as well.
try this :
provider=OraOLEDB.Oracle
How to connect to DSN created by SQlite Driver using SQL anywhere APIs from C++ code?
I am using db_string_connect() to connect to sybase adaptive server anywhere. I want to use the same function to connect to the DSN created by SQLite Driver as well but db_string_connect() API is returning sqlcode -103 ["You supplied an invalid user ID or an incorrect password."].
I have this somewhat weird requirement because I want to abstract the connection to different databases at ODBC layer. And the code to connect to sybase is already written and I want to minimize the changes in the code. Hope I am making some sense.
Thanks.
You will not be able to use a function from SQL Anywhere client library to connect directly to some other database. Typically, if you need to be able to connect and manipulate different types of database systems, you have to introduce a database layer that sits between the vendor specific client libraries and your code. This could be something you write yourself or use an existing one.