Good Morning!
I'm working on a VB6 project which reads/writes to its database via an ODBC data source stored in the system. What I'm hoping to accomplish, is to temporarily set the ODBC connection to "Read Only" so that I can see what SQL the system would generate in particular scenario without it actually writing the change to the database. The application already takes care of logging all SQL queries. Is there a way to set the system ODBC connection to "Read Only" (within the "ODBC Data Source Administrator") immediately before I perform the action I care about within the system?
I appreciate any insight!
There is no connection parameter you can set to make the session read only. Your best bet is to either use a different user ID (that has only SELECT authority), although it would seem that this might cause your app to fail when it gets errors trying to perform inserts, updates and/or deletes.
Related
I am managing a split Access database which has the front-end running locally on each user's computer (very small scale -- less than 5 users), and the back-end running on a shared network drive. However, there are a number of tables stored in an institution-wide Oracle database that we must also reference, so I have linked to them using the "Microsoft ODBC for Oracle" driver (they are linked on each front-end, not the back-end). This works well... for the most part.
If a user does not provide login credentials in the ODBC for Oracle Connect login window and instead hits "Cancel," the window closes (as expected)... but then it reopens. Repeat ad infinitum. This prevents the user from doing anything else!
How can I make it so that when a user hits "Cancel" it simply closes the window and does not link to the Oracle tables at all for this session? The Oracle tables are helpful but not essential for our workflow, so it's important that we still be able to access forms & queries even without the Oracle connection.
Unfortunately, I don't even know where to begin with this... if it is any help, I linked to the Oracle tables by going to the External Data tab, ODBC Database, Machine Data Source, then creating a new Data Source using the "Microsoft ODBC for Oracle" driver, which thankfully we all have on our individual machines. Any guidance is hugely appreciated!
Anyone know why the Netbeans IDE's Database result explorer disables CrUD operations and "Show SQL 'CrUD' Operation" when using a JDBC connection via JTOpen 9.1 driver to a DB2 for i database with Netbeans 8.1?
JTOpen is a open source JDBC driver to IBM i DB2 for i database in addition to bunch of Java Classes for interacting with the IBMi system. http://jt400.sourceforge.net/
I tried a few JDBC connection properties but no cigar...
I guess i'll have to keep browsing the IBM KB
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzahh/jdbcproperties.htm
and the JT400 source
https://github.com/devjunix/libjt400-java/blob/master/src/com/ibm/as400/access/JDProperties.java
Many DB2 for i systems are configured to not use commitment control or journaling. This is not what many toolkits expect to see. Try changing the connection string to tell Netbeans that you don't want commitment control.
Add "extended metadata=true" in the connection properties fixed my issue.
https://godzillai5.wordpress.com/2016/08/21/jdbc-jt400-setting-to-get-crud-and-show-sql-features-added-in-netbeans-with-ibm-db2-for-i/
The IBM documentation here http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzahh/jdbcproperties.htm
"extended metadata"
Specifies whether the driver requests extended metadata from the
server. Setting this property to true increases the accuracy of the
information returned from the following ResultSetMetaData methods:
getColumnLabel(int) isReadOnly(int) isSearchable(int) isWriteable(int)
apparently readonly for the result set is incorrectly assumed true, unless the ext. metadata comes back with the actual value for isReadOnly(int). I'm guessing that its assumed false because on the initial connection the connection property "Read Only" is true. It would be helpful to understand what setting on the system or the Library/Schema is causing the connection to have that property.
The most obvious reason for the original image showing just some read-only operations presented, would seem to have been the "access" attribute for the connection; i.e. if set to "read only", that would limit access to SELECT statements only. But with the new information showing the connection properties, seems the readOnly=false, so that "access" attribute should not be the origin for the issue.
I suspect that for any given TABLE, the issue might be for lack of a PRIMARY KEY CONSTRAINT; i.e. IIRC, some client database applications might prevent update-capable mode for a particular TABLE, if that TABLE is not known to have a PK.
For security reasons I asked DB team to add EXTPROC_DLLS:ONLY; but they said this:
"Please be informed that the KEY = EXTPROC1526 doesn’t refer to any
external process at all. This is just a key used by any process needs
to call Oraxxx via IPC protocol. The key can be any value and the same
key value should be passed via the tnsnames.ora"
To me, it seems wrong. Could you please help me on this? What is the exact use of EXTPROC and what happens if we don't add EXTPROC_DLLS:ONLY?
For any program to connect the oracle database you need Extproc agent.
PLS/SQL for example needs Extproc to work with oracle
You can find more information about the securit here
Ill past some of the link
Description
***********
The Oracle database server supports PL/SQL, a programming language. PL/SQ can execute external procedures via extproc. Over the past few years there has been a number of vulnerabilities in this area.
Extproc is intended only to accept requests from the Oracle database server but local users can still execute commands bypassing this restriction.
Details
*******
No authentication takes place when extproc is asked to load a library and execute a function. This allows local users to run commands as the Oracle user (Oracle on unix and system on Windows). If configured properly, under 10g, extproc runs as nobody on *nix systems so the risk posed here is minimal but still present.
and an example here
On contrary to other databases Oracle does NOT allow plugins to access it's own memory address space. In case of MySQL/PostgreSQL a .dll plugin (C stored procedure) is loaded by the main database process.
Oracle lets listener to spawn a new process by calling extproc (or extproc32). This process loads the shared library and the rest of the database talks to this process via IPC.
This approach is safer, because the external library can not crash the database nor corrupt data. On the other hand sometimes C stored procedures might be slower than Java ones.
This option can restrict path for .dlls being loaded by extproc. i.e. those created by CREATE LIBRARY statement.
PS: usage of C stored procedures is VERY rare, if you do not use them you can freely remove the whole extproc stanza from listener.ora.
PS1: there is possible scenario of exploiting the extproc feature.
User must have CREATE LIBRARY, which usually NOT granted
extproc is not configured to run with nobody's privs - but runs as oracle:dba
User creates malicious .so library, which will performs something "evil" during it's initialization.
User puts this lib into /tmp directory
User creates Oracle LIBRARY pointing into /tmp by using CREATE LIBRARY statement
User forces extproc to dlopen this library
exproc will execute evil code with OS privileges oracle:dba
When using this EXTPROC_DLLS:ONLY restriction, developers have to cooperate with DBAs, and only white-listed libraries can be used and loaded.
I'm running into a problem while linking some tables and views present on a Oracle 11g database to a Access 2007 file.
I'm using the Oracle Client (SQORA32.DLL) version 11.02.00.03.
If the view/table returns a small amount of data, there's no problem. The problem happens when the view or the table returns a "large" amount of data. I've tried to increase the buffer size on the driver (default is 64000) to see if that happens. I've also removed the "Enable query timeout" option - otherwise I would get a "Query cancelled by user" or a "ODBC - Call Failed" error.
In order to link the tables/views, I've used the "native tool" (External Data -> ODBC Database -> Link to data source by creating a linked table).
I was wondering if I could retrieve the data from the tables/views using vba. Sometimes, I (you should read "I" as "the users") may need to update data on some tables (control tables).
Please let me know your thoughts.
EDIT: Our goal with this project was to migrate from SQL Server 2005 to Oracle 11gR2. After analyzing the behaviour of the Access files regarding the SQL Server, I've concluded that the results are showing like a "cursor" - if you scroll down on the result window, it will load more.
I think that this may be the issue because, AFAIK, Oracle (driver, maybe?) pulls everything from the DB and, only then, populates MS Access.
It's a long time after this so here goes the solution. MS access has a flag for the ODBC connection as "Treat Float as Numeric". This have made the trick.
I have some simple VBA to import tables from multiple Oracle databases. I have one ODBC entry, and I connect to different databases using different credentials.
My transfer database code is simple:
DoCmd.TransferDatabase acImport, "ODBC", "ODBC;DNS=source;UID=user;PWD=pass;", acTable, "SomeRemoteTable", "MyLocalTable", True
That code works, but when I run the same command with a different user/pass immediatley after this command I get this error:
Run-time error '3011': The Microsoft Jet database engine could not find the object 'SomeRemoteTable'. Make sure the object exists and that you spell its name and the path name correctly.
Here's the catch:
The DNS, user credentials, and table names are correct. If I open access and comment either line out, then either transfer will run successfully. However, once one command runs, the other will not run until Access has been closed and reopened.
I'm guessing that there must be a way to close the first connection before proceeding to the next. Does anyone have any ideas on what I can try?
If the databases are owned by you how about setting up a dblink on one of them to the other ?
You will then only need 1 connection.