Delphi Client-Server Application using Firebird 2.5 embedded connection error - delphi

I have got a lengthy question to ask. First of all Im still very new when it comes to Delphi programming and my experience has beem mostly developing small single user database applications using ADO and an Access database.
I need to take the transition now to a client server application and this is where the problem starts. I decided to use Firebird 2.5 embeded as my database, as it is open source, and it is can be used with the interbase components in Delphi and that multiple clients can access the database simultanously. So I followed the interbase tutorial in Delphi. I managed to connect the client to the server and see the data in the example (While both are running on my pc), but when i tried to move the client to another pc, keeping the server on mine and running it to see if I can connect to the server it gave me the following error.
Exception EIdSocketError in module clientDemo.exe at 0029DCAC. Socket Error # 10061 Connection refused.
I understand that this might be because the host is defined as localhost in the client. But here is my first question. In the TSQLConncetion you can set die hostname under Driver->Hostname. The thing I want to know is how do you do this at run time, as I cannot get the property when I try and make an edit box to allow the user to enter the value and then set it via code like for example:
SQLConncetion1.Driver.Hostname := edtHost.text;
This cannot be done this way and the only way I see you can set the hostname is with the object inspector, but that is not available at runtime and I need to set the hostname on the client when the program is running the first time, so how do you set the hostname/IP address at runtime?
Im using Delphi XE2
There is still a lot of questions to come especially when it comes to deployment, but I will take this piece by piece and I appreciate the advice.

Embedded can't be used by multiple users at the same time (even if it's two applications on the same machine). See here for information on the differences between the three versions. There's also information in another SO question that might help.
As far as specifying a server at runtime, this may help:
procedure TForm1.Button1Click(Sender: TObject);
var
Conn: TSQLConnection;
begin
Conn := TSQLConnection.Create(Self);
try
Conn.DriverName := 'FirebirdConnection';
Conn.Params.Add('User_Name=SYSDBA');
Conn.Params.Add('Password=masterkey');
// Replace the dbname in the next line with the
// value obtained at runtime, as in
// Conn.Params.Add('Database=' + YourNewPathAndDBName);
Conn.Params.Add('Database=C:\FireBirdData\YourDB.fdb');
Conn.Open;
if Conn.Connected then
ShowMessage('Connection successfully made to DB');
finally
Conn.Free;
end;
end;

Related

IdFTP.Connect via proxy server

Our Delphi application is trying to connect to our website via IdFTP on a client machine using a proxy server, and I always get a 'read timed out' message. I don't know how to fix it.
My code:
IdFTP1.Host :=Website_address;
IdFTP1.Username :=Website_user;
IdFTP1.Password :=Website_password;
IdFTP1.TransferType:=ftBinary;
IdFTP1.ProxySettings.ProxyType:=fpcmNone;
IdFTP1.ProxySettings.Host :=Proxy_server;
IdFTP1.ProxySettings.Port :=Proxy_port;
IdFTP1.ProxySettings.Username :=Proxy_username;
IdFTP1.ProxySettings.Password :=Proxy_password;
IdFTP1.Connect;
...which returns a 'read timed out' exception.
Having looked on the web for possible solutions, I have tried various combinations of the following with no joy (although there might be a combination that might work, I just don't really know what I'm doing):
IdFTP1.IOHandler :=TIdSSLIOHandlerSocketOpenSSL.Create
(IdFTP1);
IdFTP1.UseTLS :=utUseExplicitTLS;
IdFTP1.NATKeepAlive.UseKeepAlive:=True;
IdFTP1.NATKeepAlive.IdleTimeMS :=100000;
IdFTP1.DataPortProtection :=ftpdpsPrivate;
The frustrating thing is I can't test it on my machine, I have to compile a new version of the application, copy it to their machine, and then see if it works.
There is nothing complex about the installation on the client side as far as I can tell. They have given me the proxy host address, and the proxy username and password are blank.
Other bits of the application connect to the same website via HTTP and the proxy server, and this works perfectly. So my logic is that it can't be firewalls or anything like that.
IdHTTP1.HandleRedirects :=True;
IdHTTP1.ProxyParams.BasicAuthentication:=True;
IdHTTP1.ProxyParams.ProxyServer :=Proxy_server;
IdHTTP1.ProxyParams.ProxyPort :=Proxy_port;
IdHTTP1.ProxyParams.ProxyUsername :=Proxy_username;
IdHTTP1.ProxyParams.ProxyPassword :=Proxy_password;
I am using Delphi XE8.
They have created a virtual server for our testing, it runs Windows 7 64 bit.
Update
Remy, is this the right idea? One problem I am having is the TIdConnectThroughHttpProxy component, what must be in the uses clause for this? Delphi is not recognizing it.
var
TempIO : TIdIOHandlerStack;
TempProxy : TIdConnectThroughHttpProxy;
......
TempIO :=TIdIOHandlerStack.Create;
TempProxy :=TIdConnectThroughHttpProxy.Create;
TempProxy.Host :=Proxy_host;
TempIO.TransparentProxy:=TempProxy;
IdFTP1.IOHandler :=TempIO;
IdFTP1.Connect;
Update 2
A point of clarity: the HTTP request that is successfully reaching the web server through the proxy server goes to a different web address than the FTP request. In other words, they both go through the same proxy server, but the destination addresses are different. Just in case this is of use.
I have now tried using Fiddler to find the problem, not sure if this is a great idea? My understanding is is that Fiddler acts as a proxy server, so I thought I would see if I encountered the same problem. Sure enough, can't connect.
To be clear about my steps:
Run Fiddler, and check the box that says 'Capture FTP requests'.
Update my IdHTTP component:
IdHTTP1.ProxyParams.ProxyServer:='127.0.0.1';
IdHTTP1.ProxyParams.ProxyPort :=Fiddler port;
Update my IdFTP component:
IdFTP1.ProxySettings.Host:='127.0.0.1';
IdFTP1.ProxySettings.Port:=Fiddler port;
So now I have removed the client setup completely, I am mirroring the problem from my local machine using Fiddler as far as I can tell. If I don't use Fiddler, everything works great. If I use Fiddler as described above, then the HTTP request works correctly, but the FTP request can't connect.
Any ideas as to what I can do to try and solve this? I'm sure it is something really stupid that I'm doing wrong.
IdFTP1.ProxySettings.ProxyType:=fpcmNone
This tells TIdFTP not to communicate with an FTP-aware proxy. If you want to use the TIdFTP.ProxySettings properties, you need to set the ProxyType so TIdFTP.Connect() will connect to the ProxySettings.Host and TIdFTP.Login() will know what kind of commands it needs to send to login to the proxy and request a connection to the next host.
Note that TIdFTP.ProxySettings only works with FTP proxies. If you need to connect to a different type of proxy, before you call TIdFTP.Connect() you will have to assign a TIdIOHandler-derived component to the TIdFTP.IOHandler property, and then assign a TIdCustomTransparentProxy-derived component to the TIdIOHandler.TransparentProxy property. To connect to an HTTP proxy (which it sounds like you need, since that is what TIdHTTP.ProxyParams works with), use TIdConnectThroughHttpProxy. To connect to a SOCKS proxy, use TIdSocksInfo.

How can I tell if my connection is using SSL?

I'm using code from a demo program using Devart's MyDac component using Delphi 2009 to connect to a remote database using SSL.
I have made and verified the certificates and keys and set the connection parameters in MyDAC to use them eg
MyConnection.protocol := 'mpSSL';
MyConnection.SSLOptions.CACert := 'C:\ca-cert.pem';
MyConnection.SSLOptions.Cert := 'C:\client-cert.pem';
MyConnection.SSLOptions.Key := 'C:\client-key.pem';
MyConnection.SSLOptions.Chipherlist := 'All';
When I tell MyConnection to connect (after setting the user name / password etc) it connects to the database with no problems.
However as a test I deliberately put in an invalid key name of 'C:\XXXclient-key.pem and it still connected OK so maybe it wasn't using SSL at all.
So my question is:
How can I use Delphi to detect if a connection is really using SSL or not?
I think I'll close this question myself as it seem far more complex than I thought it was and I need much more information before this question makes sense. It appears that the sql statement;
SHOW STATUS LIKE 'Ssl_cipher'
can help as its value will be empty if its not using ssl or will contain an value if it is.
The touble was the Mysql server I was using (ISP Nativespace) did not even have a variable name called Ssl_cipher so it looks like it doesn't support ssl anyway. Trying the same thing using another ISP I did see the variable name but it had no value, showing that was also not using ssl even I though it could do it.
It now appears that there is much more that needs doing before a ssl connection can be set up. Creating a new user on the db that only ever uses ssl, setting up permissions for them, running code on the server etc.
Not at all as simple as Devart's web page on securebridge leads one to believe!
"It is enough to place several components on the form and specify the
server address and the user login information to establish a secure
connection."
Err... not quite!

Datasnap and SocketError

I have a datasnap server with a vcl forms client. From the client, how can I handle if the server has been say shutdown and restarted with existing client connections? This scenario raises a 10053 EIdSocketError exception.
To replicate, I run up both Server and Client, make a call to the server (I use methods exposed via the DataSnap proxy generator) which succeeeds. I then shut down the server (eg Close the application) and restart it. I then attempt to make a call to the server again.
eg:
CLIENT call
sm := TsvrPolicySearchClient.Create(datClientDB.SQLConnection1.DBXConnection);
try
ds := sm.SearchPolicyByPolicy(40, WCRef, '', 3);
dspPolicyGroup.DataSet := ds;
if cdsPolicyGroup.Active then
cdsPolicyGroup.Refresh
else
cdsPolicyGroup.Open;
finally
sm.Free;
end;
dspPolicyGroup is a TDataSetProvider and cdsPolicyGroup is a TClientDataSet (I just use it locally to "store" my TDataSet result).
SERVER
function TsvrPolicySearch.SearchPolicyByPolicy(AClientId: Integer; WCRefNum, ClientRef: string; SearchMethod: Integer): TDataSet;
begin
spPolicyByWCRef.Close;
spPolicyByWCRef.ParamByName('p_client').AsInteger := AClientId;
spPolicyByWCRef.ParamByName('p_search_method').AsInteger := SearchMethod;
spPolicyByWCRef.ParamByName('p_wc_refno').AsString := WCRefNum;
spPolicyByWCRef.Open;
Result := spPolicyByWCRef;
end;
I would think this is regularly encountered by people seeing that it's quite easy to replicate. Should I place a "Test Connection" call or something first (such as a method TestConnection) before each call to check for EIdSocketError (and equivalent) and handle? Or is it more a design flaw perhaps?
Thanks
My scenario:
Client application connect to DataSnap Server (TCP/IP, remote server)
Client request a DataSet (using DataSnap server methods). TClientDataSet
Client downloaded dataset
Server shutdown (taskkill, close application no matters)
Client request a DataSet againt (ehhrrr Socket Error)
Solution:
On client I catch exception (AppEvents.OnException)
Recognize that is Socket error from connection to DataSnap server
I show dialog window with information that connection is lost. User can click "RETRY" - if so,
Free and re-create DataSnap client module and initialize connection
Try to request dataset (special dataset for connection test) if application catch exception entire process works from the beginning.
After this operation my Client re-connect to DataSnap server and can request dataset using new TCP/IP connection. Of course user can close dialog, but then application is turn off.
I think this can help you. I tried many others solutions but this proved to be the best. Moreover algorithm also supports the loss of connection with the client's fault.
The easiest workaround for this problem is to change the TDSServerClass LifeCycle attribute to Invocation.
This will cause you to have a stateless server, and the server will create a new session per request. But, you will be able to close and reconnect the server without interrupting the clients connection.

Delphi Client-Server Application using Firebird 2.5 error [duplicate]

This question already has an answer here:
Closed 11 years ago.
Possible Duplicate:
Delphi Client-Server Application using Firebird 2.5 embedded connection error
I have got a lengthy question to ask. First of all Im still very new when it comes to Delphi programming and my experience has beem mostly developing small single user database applications using ADO and an Access database.
I need to take the transition now to a client server application and this is where the problem starts. I decided to use Firebird 2.5 embeded as my database, as it is open source, and it is can be used with the interbase components in Delphi and that multiple clients can access the database simultanously. So I followed the interbase tutorial in Delphi. I managed to connect the client to the server and see the data in the example (While both are running on my pc), but when i tried to move the client to another pc, keeping the server on mine and running it to see if I can connect to the server it gave me the following error.
Exception EIdSocketError in module clientDemo.exe at 0029DCAC. Socket Error # 10061 Connection refused.
I understand that this might be because the host is defined as localhost in the client. But here is my first question. In the TSQLConncetion you can set die hostname under Driver->Hostname. The thing I want to know is how do you do this at run time, as I cannot get the property when I try and make an edit box to allow the user to enter the value and then set it via code like for example:
SQLConncetion1.Driver.Hostname := edtHost.text;
The thing is there is not such property to set, so how do you set the hostname at run time?
Im using Delphi XE2
There is still a lot of questions to come especially when it comes to deployment, but I will take this piece by piece and I appreciate the advice.
That means that the server: port your program is trying to connect to
is refusing your connection. Could be a firewall related issue on
either your server or your own machine.
Try using telent to connect to the server. If that succeeds you know it a problem with your machine's configuration.
Check these links for more information :
How TO Fix Socket Error 10061 Connection Refused Easily
Problem Loading (python blocked by firewall)

Delphi 2009: How to communicate between Windows service & desktop application under Vista?

How can a desktop application communicate with a Windows service under Vista/Windows2008/Windows7? The application needs to send small strings to the service and receive string responses back. Both are written in Delphi 2009. (Please provide sample code also)
The way to go is named pipes, you'll probably have to take a look at the communication across different Integrity levels.
This article explores how to do this in vista. Although it's written in c++ it's just basic Windows API calls, so it should translate fast enough to Delphi.
If you want to search for more on this subject, this communication is called Inter Process Communication, but a better search term is IPC.
Using Indy you can relatively easy create a TCP connection between your apps. Especially if you only need to send string messages. For the client (in your case the desktop application) it's basically
var
Client : TIdTCPClient;
...
Client.Host := 'localhost';
Client.Port := AnyFreePortNumber;
Client.Connect;
Client.IOHandler.Writeln (SomeString);
Response := Client.Readln;
...
Client.Disconnect;
For the server (would be the service in your case)
var
Server : TIdTCPServer;
Binding : TIdSocketHandle;
...
Server.DefaultPort := SameFreePortNumberAsInClient;
Binding := Server.Bindings.Add;
Binding.IP := '127.0.0.1';
Binding.Port := Server.DefaultPort;
Server.OnConnect := HandleConnection;
Server.OnDisconnect := HandleDisconnection;
Server.OnExecute := HandleCommunication;
Server.Active := True;
Just implement the HandleCommunication method. It is called whenever the client decides to send something. Example:
procedure MyClass.HandleCommunication (AContext : TIdContext);
var
Request : String;
begin
Request := AContext.Connection.IOHandler.Readln;
if (Request = Command1) then
HandleCommand1
else if (Request = Command2) then
HandleCommand2
...
end;
IIRC a service is only allowed to have a graphical user interface OR have network access, so this might be a problem if your service needs a GUI (which you should avoid anyway, see this question). I don't know how this is handled in Windwos Vista and later though.
Have a look at the answers in Exchange Data between two apps across PC on LAN which is pretty much the same question nowadays. Local comms via TCP is standard. As I said in my response there, solutions that use "Remote Procedure Call" type interfaces work well. I use RemObjects SDK for this sort of thing, and it makes it easy to expand to control across the network if you wish to later.
Both of these allow you to create a connection that for most of your code is "transparent", and you just call an interface which sends the data over the wire and gets results back. You can then program how you usually do, and forget the details of sockets etc.
You have to change the service user from localsystem to networkservice and then the service can use TCPIP fine. I have several services which use TCPIP for an external control hook. Just make sure your service port is configurable so you can handle any collisions.
A few of my control interfaces are based on XML pages served from an internal HTTP server. This allows me to remotely check on status of the service using any web browser which can reach the port on that machine. The advantage of using HTTP over other methods is that it works well when you need to work over existing network hardware.
If your ONLY going to be communicating locally, then named pipes, mail slots or a memory mapped file might be the best method.
I haven't tried it, but I think you could use named pipes.
I use in my service applications a component set, freeware with sourcecode called Simple IPC.
Search torry.net. It has worked very well in all of my service apps when communicating with a desktop app.
John

Resources