We have a D7 vcl app that uses dbexpress to connect to oracle (via the devart oracle driver for dbexpress). We converted this app to XE5. In D7 the dbxdrivers.ini and dbxconnections.ini files have been deployed in the same directory as the exe and the application read the them from this location without any intervention (i.e. dbexpress found automatically all the settings)
In XE5 deploying the dbxconnections.ini file doesn't work in the same way it worked in D7, in other words the application doesn't seem to use/find the two ini files when they are deployed in the same folder as the exe.
Based on my observations and reading the delphi code, I need to call the TSQLConnection.LoadParamsFromIni method and pass the dbxconnections.ini file name, otherwise the TSQLConnection object ends up reading the location from the registry: HKCU\Software\Embarcadero\BDS\12.0\DBExpress\Connection Registry File. dbexpress will read the dbxdrivers.ini from the exe directory, if it is there.
Any thoughts on this? Could you please confirm that this is how it's done?
Thanks
Update: After more testing here is the behavior that I am seeing:
If the HKEY_CURRENT_USER\Software\Embarcadero\BDS\12.0\DBExpress key is not present at all, and the dbx***.ini files are deployed only in the exe folder the XE5 app uses them without having to call LoadParamsFromIni.
If the HKEY_CURRENT_USER\Software\Embarcadero\BDS\12.0\DBExpress key is present with all the settings (Connection Registry File etc.) pointing to the ini files in the public folder, and the dbx***.ini files are deployed only in the exe folder, then the app doesn't read the ini files from the application folder and I need to explicitly call LoadParamsFromIni.
I think it is more reliable to call the LoadParamsFromIni than relying on the default behaviour of dbexpress.
Related
Using:
Delphi Berlin update 2
Indy version 10.6.2.5341
Websocket (sgcWebSocketClient, 4.1.7.0 )
We have an application that works in some machines and doesn't in others. The environment is the same, windows 10 recently installed without any other program. Hardware is the same because we have a lot of equal hardwares here.
Well, when we try to connect in a security way, using SSL we get "could not load SSL library". We don´t have OpenSSL installed in any machines (even the machines that works fine)
We have tried the support with the ESEGECE... but didn´t solve until now.
We tried to register the DLLs using regsvr32 but we get some errors and couldn´t register. These are the messages that we get:
The module "libeay32.dll" was loaded but the entry-point DllRegisterServer was not found. Make sure that "libeay32.dll" is a valid DLL or OCX file and then try again.
Or we get:
The module "C:\Central\libeay32.dll" failed to load. Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. The specified module could not be found
The DLL files are the right one because we copy from ESEGECE examples.
We used WhichFailedToLoad() to figure out what is happening, but we get "Failed to load libeay32.dll" message.
We also tried to use SafeLoadLibrary() pointing to the place where DLL is located.
We did a test with IdOpenSSLSetLibPath() also but not successful.
GetLastError() returns 0.
We found similar questions about this here, tried the solutions as you can see above, but without success.
Do you have any other suggestion?
You cannot use regsvr32 to register the OpenSSL DLLs because they are not ActiveX/COM servers.
Assuming you have both ssleay32.dll and libeay32.dll together, the most likely reason for libeay32.dll to fail to load is because either:
you are using a 3rd party distribution of libeay32.dll or ssleay32.dll that have external dependancies on other DLLs, such as the Visual C++ runtime, which you do not have installed. Use a tool like Dependency Walker to verify.
Try using the OpenSSL DLLs that are available on Indy's Fulgan mirror, as they do not have any external dependencies (except to each other):
https://indy.fulgan.com/SSL/
your app is 64bit but you are using 32bit versions of libeay32.dll or ssleay32.dll, or vice versa.
my application works fine on the computer where I made it but on another
machines it displays error: "Transaction not connected".
I installed pack created by Runtime Packager and added a couple
of DLLs to the application path on the target machine. Still the same
problem.
My question is if I should use dnsless connection to make it work?
Or maybe inform the target PC about the required ODBC configuration?
If yes - how to do that?
I read a lot about odbc.ini, system variables, registry entries etc.
but now I got it all mixed up and have no clue what to do.
I'll be very grateful for your help.
Kris.
Personnally, I use DSN. So, the only thing the PowerBuilder knows is the DSN name. On that base, I establish the connection.
On the target PC, I configure ODBC with this very same DSN name and the necessary drivers. This way, you have some flexibility in the deployment. For instance, I can develop using DSN 'db', referring on my developper's machine to database 'dev' or the server 'server_dev' and deploy on a target machine where 'db' refers to 'prod' database on server 'productionServ'.
Compatibility issues aside, it can even be that the first one is MySQL and the other onee Oracle.
It is anyway crucial to install the drivers allowing you to access the desired database on the target machine and, if you use DSN, to configure it.
Since you said you got confused with odbc.ini & registry, lets start from there.
Assuming the required ODBC connection is configured in your computer (as you said),
Open registry editor (Win+R, regedit) in your computer.
Go to path "HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI". NOte: "HKEY_LOCAL_MACHINE" can be used for multi-user computers.
Right click on your "ODBC Connection" and export. Save the file(*.reg). (opening this file in notepad will give you some ideas on how it is configured.)
Also do the same for "HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources\". Merge both files into one (open the *.reg files in notepad and merge the text).
Now you have the following options to setup the ODBC in your target machine(s):
This file(*.reg) can be executed on the target machine (beware, the drivers path might be different in the target machines.).
If you have an installer, try to include code to write the registry values from the installer.
Use PB function RegistrySet() to create your own ODBC connection if it does NOT exists.
Brief of what we are trying: Export registry entries (as a *.reg file) from the development machine and create similar registry entries on target machines using any of the 3 methods listed above.
I'll be reinstalling Windows and I wondered if there's a way to backup/restore Delphi license info so I don't "lose" one of my installations for that.
In other words - is there a way to uninstall Delphi, reinstall Windows, reinstall Delphi without that being treated as a "new" installation?
[I want to completely wipe out my computer and start out from scratch. I'll be reinstalling XE5, XE7, and 10 Seattle.]
The .slip files used for registration info are in C:\ProgramData, in either the CodeGear or Embarcadero folders depending on which version of the IDE you're using.
I've successfully copied the files from these folders to a thumb drive and moved them to a new computer. Note that part of the registration information is the local computer name, so in order to work on a different machine (or a clean Windows install on the same machine) the computer name needs to stay the same. Just name the computer the same, copy the .slip files to the same location on the new machine, and then install Delphi/RAD Studio.
To be on the safe side, I always copy the entire folder (including all subfolders and their contents) to make sure I've gotten everything the IDE needs.
I had a similar problem when renaming my Windows 10 computer. Apparently the license is bound to the computer name. I had to re-register Delphi after renaming my computer but failed because of the limit of my license key.
Solution was renaming back my computer and renaming C:\ProgramData\Embarcadero\.cgb_license.corrupted and C:\ProgramData\Embarcadero\.licenses\.cg_license.corrupted to files without the .corrupted as suffix. My licence slip file was C:\ProgramData\Embarcadero\.2016_2.#############.slip.
OK, new to rad studio, and enjoying it.
We have a cross=platform product, and would like to configure XE6 to automatically deploy to compiled .exe & Dll files to specified buckets in S3.
We have looked at the cloud exploerer example which came with samples and can load the files manually using REST.
http://docwiki.embarcadero.com/CodeExamples/XE6/en/DataSnap.Cloud_Explorer_Sample
and have checked out how to specify an output folder
Where can I specify an output folder for DLLs?
As discussed we are not that familiar with XE6, and while they have something called a 'platform deployment manager' we don't want to setup up and EC2 instance to facilitate the process.
Does anyone have any sample scripts or advice on how to configure the output path to use the REST protocol to put the compiled files up on S3 automatically?
I have a ISAPI application written with Delphi. The application is compiled with runtime packages. Basically, all related bpls should deploy to an ISAPI enabled directory as well in order to get the ISAPI dll works. However, I always face errors when invoke ISAPI dll.
If my ISAPI dll doesn't compile with runtime packages, then it works fine.
The runtime packages should be the cause of the problems. The only solution so far I have is add the runtime packages path to system environment variable: %path% and restart the PC.
Is there any other solution available by not altering the environment variable?
I am using Windows 7 and IIS 7 and Delphi 2010.
For the case where the ISAPI DLL and the runtime bpl's are in the same directory, check the file permissions on your ISAPI DLL and the runtime .bpl files, and make sure that the Internet Guest account has read+execute access to them.
Have you tried placing .bpl files in directory where ISAPI dll is?
If this do not work then create installer for your ISAPI and this installer should copy all needed .bpl files to Windows system directory (you can get it using GetSystemDirectory() API function, usually this is <WindowsDir>\system32). For InnoSetup this is {sys} file destination.
The BPL files MUST be in the system path of the machine OR in the directory of the executable (which in this case I believe is svchost.exe?). Now, the fun part. As each application is launched it grabs a snapshot of the environment at that time. If you add to the path, you will have to reboot the machine for it to become active, OR restart the application (which in this case involves restarting the OS).