0

I got the stopper error below in my apps. I used Delphi Berlin 64bit compiler. And also used the dbxora.dll as dbxpress driver default from embarcadero. Connected to Oracle 12c DB server using TSQLConnection component.

DBX Error: Driver could not be properly initialized. Client library may be missing, not installed properly, of the wrong version, or the driver may be missing from the system path.

How can I fix this?

AJNeufeld
  • 8,526
  • 1
  • 25
  • 44
Taruna Feri S
  • 1
  • 1

1 Answers1

2

A DB Express driver is not always sufficient on it's own to connect to some data sources. For certain data sources (most of them in fact) you also require the client drivers for that data source, usually provided by the database vendor themselves.

Oracle is one of these.

As well as the DB Express driver you also need to install the Oracle Client software provided by Oracle. You also need to ensure that you install the correct version.

i.e. in your case since you indicate you are building a 64-bit application then you will need the 64-bit Oracle client.

If you (or your intended users) already have the 32-bit Oracle client installed then you might consider building your application as a 32-bit application instead, unless you absolutely need 64-bit capabilities.

Deltics
  • 22,162
  • 2
  • 42
  • 70
  • Yes, indeed. I installed the 64-bit Oracle 12c Client on this. All the environment 64bit already. And this issue is still emerging. Fyi, I used OCI access in this case. – Taruna Feri S Aug 10 '16 at 03:43
  • And are you *certain* you are building (and running) an EXE for the Windows x64 target ? If you are then the next thing I'd check is whether it is on the path, as required. And of course first principles: Can you successfully establish Oracle connections using *other* 64-bit apps on the same machine ? – Deltics Aug 10 '16 at 07:26
  • This also happens, to my horror, if you install the 64 bit client software and you compile your Delphi project with 32 bit. – sandman May 15 '18 at 14:58
  • 1
    @sandman yes, of course. 32-bit apps use 32-bit DLL's and 64-bit app's use 64-bit DLL's. Neither one can use the other without some shenanigans going on inbetween. e.g in the case of printer drivers, for example, the Windows provides 32 and 64-bit application drivers and takes care of mapping printer calls down to the underlying 64-bit printer drivers. But for proprietary interfaces such as database drivers etc, it's up to the vendor to provide that sort of mapping (called "thunking") and if they don't then the 'bitness' of your apps **must** match the bitness of the driver. – Deltics May 15 '18 at 19:28
  • Most of our work environment evidently uses 32 bit legacy software, as lots of software broke when the 64 bit instantclient was tested. Wonder if the world will ever be fully 64 bit compliant... sigh. – sandman May 16 '18 at 09:11
  • 1
    @sandman probably not, simply because it doesn't *need* to be. Unless of course a 64-bit OS removes support for 32-bit processes completely (looking at you Apple) then the decision as to whether to build for 32 or 64 bits (64-bits is not all gravy) comes down to whether a particular application really needs it. Mostly that means server apps, not desktop/clients. Whether to continue 32-bit support in an OS comes down to weighing the cost/complexity of continuing that support vs the #'s of apps/users/developers who will be inconvenienced for no direct benefit to them. – Deltics May 16 '18 at 19:29