Does anyone know how to set Firebird into mixed mode like H2 can with the AUTO_SERVER=TRUE option?
The H2 automatic mixed mode is described here.
What about serialized mode?
Notice it should be possible because it is mentioned here
A Firebird server - by default - accepts multiple connections. You don't have to do configure anything to enable that. The only exception is if the administrator of the server restricted access for maintenance.
Firebird embedded itself cannot serve as a normal server (accepting connections from outside the client application that embeds it), but depending on the Firebird version and the OS it is possible that the database file can be shared with a 'normal' Firebird server on the same machine.
Your second link is about accessing a database on network drive, which is not possible (or at least prevented by default) because that can cause corruption by limitations of locking and forced write guarantees. Also understand that in a database server like Firebird all clients of a single database (should) access the same server, and the server accesses a database file local to the server machine.
Related
I am trying to open test url
jdbc:h2:tcp://localhost/~/test
from H2 web interface, but it says
Database "D:/Users/USERNAME/test" not found, either pre-create it or
allow remote database creation (not recommended in secure
environments)
How to fulfil either pf propositions?
If you have a separate H2 Server process (launched from a jar file or as a service), you can open H2 Console from its icon in the system tray and use jdbc:h2:~/test URL in it, this copy of H2 Console should be able to create embedded databases automatically (unless remote access from other hosts was enabled). Other Java processes will still need jdbc:h2:tcp://localhost/~/test URL for connections to this database and they can use this remote URL after creation of embedded database on the server.
If H2 Console and TCP Server of H2 were launched from your application, your application should create this database by itself by establishing a connection with the same embedded URL jdbc:h2:~/test first.
You can also use a shell tool or any other way to create your database:
https://h2database.com/html/tutorial.html#creating_new_databases
All these ways also require the jdbc:h2:~/test URL to be used during creation.
There is also a flag to enable remote database creation, but this feature opens a security hole, either local (if remote connections are disabled by default) or remote if they were explicitly enabled. You should avoid usage of this feature.
I have a server with IIS that hosts web sites.
Some of those web sites (Silverlight) must connect to an Oracle Database to perform queries via OleDb, but they cannot.
Here are the results of what I tested :
'msdaora' provider is not registered on local machine when I run it in the web site
ORA-01019: unable to allocate memory in the user side (when I try to connect with a test console program without administrator status)
Connection OK (with the same test console program WITH administrator status)
ORA-12154: TNS:could not resolve the connect identifier specified when trying to switch to another method of connection (from OleDb to Oracle.ManagedDataAccess.Client)
I went through countless info about these kind of errors but I couldn't find any working solution.
Here is what I tested :
giving "create global objects" right to the relevant users (no change at all)
installing several Oracle clients one after another. Best result is with 10.2 client 64b (where my test program can connect while having administrator rights). The install is clean (no several Oracle folders nor several Oracle environment variables at the same time)
disabling warnings concerning the administrator elevation (ie no confirmation pop up during elevation) : no change at all
checking RAM usage (plenty of memory under the foot)
Additional infos :
The connection string is
Provider=msdaora;Data Source=HOSTNAME;User Id=USER;Password=PASSWORD
Same connection string used with OleDb and Oracle.ManagedDataAccess.Client.
The tsnames.ora file exists (and works, as show my succesful attempt with the administrator test program)
It's working on an older web server, but there are too much differences for me to find any meaningful one (different Windows, 32/64b, different IIS versions, different Oracle client)
Any idea ?
There are several points:
Microsoft msdaora provider for OLE DB is deprecated for ages. You should prefer the Oracle Provider OraOLEDB.Oracle.
Oracle Client and OLE DB provider and IIS application have to have the same architecture, i.e. all must be either 32 bit or 64 bit, you cannot mix them. (ancient msdaora is not available for 64 bit). However, ODP.NET Managed Driver (Oracle.ManagedDataAccess) works for both 32 bit and 64 bit.
When you use ODP.NET Managed Driver then Provider=MSDAORA is not needed in ConnectionString. I assume such attributes is ignored or you just missed to mention it.
Version of Oracle Client and OLE DB provider must match (even minor version). Due to COM limitation you cannot install more than one OLE DB provider for 32 bit and 64 bit each.
Search pattern for tnsnames.ora file in OLE DB is different to search pattern in ODP.NET Managed Driver. Verify following items:
OLE DB reads your Registry for TNS_ADMIN value, the ODP.NET Managed Driver does not.
ODP.NET Managed Driver uses your .NET config file (i.e. web.config, machine.config) to determine location of tnsnames.ora file, the OLE DB does not.
According documentation ODP.NET Managed Driver does take into account the TNS_ADMIN Environment variable and folder %ORACLE_HOME%\network\admin. However, according to my tests it does anyway.
Regarding connection failure is depending on "Rus as Administrator" check permissions of your Oracle installation folder.
I have a legacy application, which connects to the configured Oracle database.
It seems it has some logic that alters the database credentials as it is unable to successfully log in to the Oracle database, while sqlplus started on the same machine is able to log in.
The error I am getting is: [DataDirect][ODBC Oracle Wire Protocol driver][Oracle]ORA-01017: invalid username/password; logon denied
How to find out what is the database username and password that are sent to the database?
What I have tried so far:
Enabled auditing of failed sign-on attempts on Oracle (audit create session whenever not successful). It does not solve the issue, because it only logs the username, which seems to be correct, without the password.
Used a sniffer to eavesdrop the network traffic between the machine running the application and the database, but since Oracle's TNS protocol is encrypted, it did not help a lot.
Started a server using netcat on port X, provided port X in the application configuration file. The application did connect to my server, that is how I know the application is connecting to the correct server. But since the TNS protocol is pretty complex (requires a series of messages to be exchanged between the client and the server) I hope there is a simpler why of achiving what I want without having to reverse engineer Oracle and implementing my own server.
Enabled tracing of the JDBC driver (Trace=1, TraceFile, TraceDll). The trace file shows the correct username, but obviously the password is not getting logged.
My environment:
Database: Oracle 11g
Application runs on: Solaris
Application uses: DataDirect ODBC Oracle Wire Protocol v70
I not sure, but if connection established by ODBC driver (as described in question tags) then you can try ODBC sniffing tools like ODBC Tracing.
Citation:
Password "Sniffing" Using Trace
ODBC provides a means for tracing the conversation taking place between the driver and the host database. Used by developers for testing purposes, the tracing feature is designed to help programmers find out exactly what is going on and to help fix problems. However, tracing (also called "sniffing") can be used by nefarious bad guys to retrieve user passwords.
When tracing is enabled, communications with the host are written to a file. This includes the user ID and password, which are captured in plain text.
Update
SQLPlus connects to Oracle with OCI interface, but DataDirect ODBC driver uses it's own proprietary implementation of communication protocol. So, most probable point of failure is driver misconfiguration or incompatibility.
DataDirect provides some tools for ODBC drivers diagnostics, but only option applicable to case described in question is using snoop utility, which acts like a netcat which already tried.
Because connection failed at credential verification stage, the most probable source of error is using localized symbols for user name or password. There are some issues with Oracle authentication process, listed in DataDirect Knowledge Search (search for ORA-01017).
It seems that DataDirect provides two separate version of driver with and without Unicode support, therefore one of possible points of failure is to connecting with non-Unicode version of driver to Unicode version of database and vice verse.
P.S. For now I don't have any experience with DataDirect ODBC driver. So it's only suggestions about possible source of failure.
For testing purposes. One option is to disable network connection but this seems to disable IIS for some reason.
I would like to prevent a web service to have a connection to a db on different machine. Changing anything on server side is not an option.
EDIT: I have to do this on specific point during the Web Service's (and it's consumer's) execution. I'm trying to simulate a situation where the connection to db is suddenly lost while serving a request.
If you are using TNS based naming for the database, remove the name temporarily from the tnanames.ora file.
To do it at the OS level, configure your Windows 7 Firewall (advanced seting). Add an outbound block rule for the IP/port of the DB server.
I am installing Firebird (v1.5.5 - I know it's old but it works) on a new computer which is running Windows 7. I have installed the classic server version as a service. According to documentation at the Firebird site, I modified the firebird.conf file so that IPCName would be global\FirebirdIPI; I did this while the service was not running.
Despite all my efforts, I have been unable to access any of the databases which I copied to this new computer via ISQL. FWIW, the EMS SQL 2005 manager program is successful in accessing the databases, but this program apparently has a direct method which does not require fbclient.dll.
What else should I be checking?
Update from a few days later. After wasting a great deal of time with Windows 7, we decided to downgrade the computer and run XP. After installing the superserver version of FB 1.5.5, I can run my programs and access the databases which are stored on this computer. Attempts to access the databases from other computers connected on the network failed with a variety of error messages, but normally something like 'i/o error for file !firebird!\db\q400.fdb'.
In order to allow people on the network to continue to access the databases, I revived the NT server and started the Firebird service - and all the programs can access these databases successfully from remote computers!
To simplify matters, there are three computers on the network:
the NT server ('zorcomp'), which is running the Firebird service; the fdb files reside on this computer in a directory called 'db' which sits under a shared directory called 'firebird'
a computer running XP, called 'kivserver', which also has a shared directory called 'firebird' and underneath that a directory called 'programs'. Copies of all the fdb files reside in a directory called 'db'.
a computer running XP, which maps \zorcomp\firebird to disk L: and \kivserver\firebird to disk T. From this computer, I can run a program sitting in T:\programs and get it to access successfully a file sitting in L:\db. If I stop the FB service on zorcomp and start the same service on kivserver, the same program cannot access files sitting in T:\db.
I hope this is clear enough. For the life of me, I can't see any difference between all the files which are residing in \kivserver\firebird to those which are sitting in \zorcomp\firebird - but somehow there is a difference!
Obviously, I don't want this arrangement to continue - the NT server has to be retired honourably.
Further edit. I now have the firebird server running on 'kivserver' (NT). I can access the database files locally.
Computers running Win7 can now access these database files using a connection string \\kivserver\firebird\db\database.fdb.
Computers running XP cannot access these database files, although IIRC wisql did succeed with \\kivserver\firebird\db\database.db.
The NT server has been disconnected from the network.
TIA,
No'am
AFAIK EMS SQL uses fbclient.dll (or a wraper around it).
If the only thing you want is to access the databases, I suggest you to do so using TCP protocol instead of the local protocol. To do it connect like this:
c:\>isql localhost:c:\path\to\db.fdb -u sysdba -p masterkey
Unless you're avoiding TCP or the machine have no local interface enabled, it will do the work for you.
Try using this to connect to your database:
hostname:drive:\complete path\filename.fdb
or
\hostname\drive\complete path\filename.fdb
May I know the component you're using?
If your clients are Windows 7 then you might try to use \\hostname\sharename\filename.fdb instead of drive:\filename.fdb connection string.
Several months later, the NT server was somewhat abruptly retired when it displayed 'MBR error' on rebooting after someone unlugged it by accident. Thus I was left with no option but to start running the Firebird server program on 'kivserver'. The connection problems returned.
Eventually I was able to solve the problem with the following connection string
10.0.0.202:e:\firebird\db\manager.fdb
where 10.0.0.202 is the ip address of the server, and e:\firebird\db the directory in which the database sits, relative to the server itself.
I hope that someone else, some time, will find this information useful.