Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 3 of 3 total |
RemoteProcedure: client app freezes while waiting for server answer |
Thu, Apr 8 2010 6:39 AM | Permanent Link |
Luis Conception Gonzalez | Hi!
I use the following code to send a message to the server from a client: CLIENT SIDE: with DBISAMSession1 do begin RemoteParams.CreateParam(ftString,'Texto').AsString:=inputstr; CallRemoteProcedure('Message'); if RemoteParams.ParamByName('Result').AsString<>'' then ShowMessage(RemoteParams.ParamByName('Result').AsString); end; SERVER SIDE: [OnServerProcedure Event] if (AnsiCompareText(ProcedureName,'Message')=0) then begin with ServerSession do begin if RemoteParams.ParamByName('Texto').AsString<>'' then begin form1:=tform1.create(nil); try form1.memo1.text:=RemoteParams.ParamByName('Texto').AsString; form1.showmodal; RemoteParams.Clear; if form1.edit1.text<>'' then RemoteParams.CreateParam(ftString,'Result').AsString:=form1.edit1.text; finally form1.release; end; end; end; end It works fine, but the problem is that client PC has to wait until server answers, and client application is 'freezed'. So, if there is nobody at Server PC, Client application is not usable at all. Is it possible to solve this? Thanks! -- Santy C |
Thu, Apr 8 2010 1:43 PM | Permanent Link |
Raul Team Elevate | Yes - you're intentionally blocking on the server so it would freeze. There are couple of issues that i think you have 1. Since server side procedure runs in the context of the remote sessions thread it also means that you have blocked the server so even if client would not be freezing it's BDISAM connection would be dead anyways (maybe somebody else can confirm this) 2. You could in theory use the SendProcedureProgress in server procedure and then handle OnRemoteProcedureProgress event on client so it's not blocking. 3. Finally it seems you're assuming server runs as interactive application. It can run as service in which case this might not even work if there was a user logged in and looking at screen (if service could not interact with desktop). Overall though i personally think this is not good design in the first place - to block on server with modal form. You would be better off doing a non-blocking solution. Unfortunately async is a lot more complex. i think main question is what exactly are you trying to achieve ? If you're just trying to open a form on server to get user input then a small external app and server side table that app populates and client checks might be a quick 'n dirty solution (server side proc would just create a row in table and launch app for example). Raul |
Thu, Apr 8 2010 2:46 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Luis,
<< It works fine, but the problem is that client PC has to wait until server answers, and client application is 'freezed'. So, if there is nobody at Server PC, Client application is not usable at all. >> The client will timeout after the TDBISAMSession.RemoteTimeout time period, provided that the client application was connected already. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Thursday, March 28, 2024 at 06:05 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |