Using EDB 2.26 b5

I have a VCL application which has been happily running in f/s mode
since before the birth of EDB.
Clearly that cannot go on much longer given the messages emanating from
Microsoft about SMB, Workgroups and Homegroups.
So I plan to switch to c/s around the turn of the year.

However, the application is for running sports competitions and it
typically runs in any of the following environments:
  * standalone laptop with no network connections (wired or wifi)
  * typical home wifi network (for event preparation)
  * ad hoc LAN strung together at a sports venue by amateurs using
retail kit and cables - possibly with an Internet connection of some
description.
I think all of the above means the Server should not be running as a
service as it is only needed ocasionally.
   
In the first two of the above it will be single instance of the app so
the Engine could be etLocal with no DBServer.  But if a stand alone
laptop (no LAN) can still use the Server it may be convenient for me
(or the user) to fire up the Server anyway, if necessary, so that I do
not need to change the Engine's type.  I could do with some
clarification on this point.

When it comes to running an event with several instances of the
application on the LAN how should I handle the server(s)?
I suspect I should have only one instance of the server on the LAN  as
there will be no need for several, and if several were running I guess
there may be port issues or the like, or is the IP address the key?

So will I have to:
  * 'educate' my amateur users to manually launch a server on only one
host (the one with the master database!)?
  * provide a simple means for each instance of the application to be
connected to the server (hmm, I seem to remember an NG message from Tim
about providing a means to 'discover' a server on a LAN - did that ever
happen)?
   
Of course I have a few other questions, but any answers to the above
will help to get me started.  TIA  

Malcolm

Malcolm


There's no problem with having an application switch between f/s & c/s. I use a small ini file. I've stuffed pretty much everything below.

You're right in that you only want one server running. The example below used the computer name but you could use ip address.

<<  * 'educate' my amateur users to manually launch a server on only one
host (the one with the master database!)?>>

<<* provide a simple means for each instance of the application to be
connected to the server (hmm, I seem to remember an NG message from Tim
about providing a means to 'discover' a server on a LAN - did that ever
happen)?>>

Unless there is a way to programmatically discover a server then this is liable to be a bit of a problem. However, you've overcome it with f/s where you need to get the users to point their systems at the file server so its not impossible. Look at how you do that and apply the same logic to client/server.

One thought that crosses my mind is to modify your software to grab a list of PCs on the LAN, ask "is this the server?" if yes ShellExecute the server engine on that machine, if not ask "which it is then?".  It should also be possible (never tried it though) to loop round the PCs on the network, try opening a table, if it succeeds set that as the server otherwise launch the server. Both approaches rely on the users not trying to run the program on every PC simultaneously - I bet someone will.

If you go down these routes let me know if you need help and I'll see what I can do.


WHAT I DO......
ini file
*******************************
D:\NLH Associates\TfR


{C/S}NLHZero
D:\NLH Associates\TfR
******************************

Only line one counts - the others exist to make it easy to switch (I just cut'n'paste)

Inside the app in the datamodule

procedure Tdm.DataModuleCreate(Sender: TObject);
var
sl: TStringList;
begin
TfREngine.Signature := Copy(Digest(156), 1, 10);
TfREngine.TempTablesPath := GetWindowsTempPath;
edbParams.Sig := TfREngine.Signature;
edbParams.TempPath := TfREngine.TempTablesPath;
SetLocalRemoteDetails(TfRSession);
end;

in a utility unit

procedure SetLocalRemoteDetails(WhichSession: TEDBSession);
begin
WhichSession.ExcludeFromLicensedSessions := True;
WhichSession.LocalTempTablesPath := edbParams.TempPath;
if edbParams.IsRemote then begin
 WhichSession.SessionType := stRemote;
 WhichSession.RemoteEncryptionPassword := edbParams.Encryption;
 WhichSession.RemotePort := 12010;
 WhichSession.RemoteSignature := edbParams.Sig;
 WhichSession.RemoteAddress := '';
 WhichSession.RemoteHost := edbParams.ConfigPath;
 WhichSession.RemoteEncryption := True;
 WhichSession.RemotePing := True;
 WhichSession.RemotePingInterval := 20;
end else begin
 WhichSession.SessionType := stLocal;
 WhichSession.LocalSignature := edbParams.Sig;
 WhichSession.LocalConfigPath := edbParams.ConfigPath;
 WhichSession.LocalEncryptionPassword := edbParams.Encryption;
end;
end;

and in the project (dpr) file itself - I just cut'n'pasted the lot so there's some surplus code

begin
// Application.ModalPopupMode := pmExplicit;
IsMultiThread := True;
edbParams.IsRemote := False;
DisableProcessWindowsGhosting; // this isn't needed in the IDE only outside it
{$IFDEF TFRDEV}
if DebugHook <> 0 then begin
 ReportMemoryLeaksOnShutdown := True;
 SetMMLogFileName(PChar('Z:\Leaks\TfR.txt'));
{
1. set TD32 on
2. enable the FullDebugMode compiler define in the FastMM4Options.inc file
}
end;
{$ENDIF}
aPath := IncludeTrailingPathDelimiter(ExtractFilePath(ParamStr(0)));
if FileExists(aPath + 'TfR.ini') then begin
 sl := TStringList.Create;
 sl.LoadFromFile(aPath + 'TfR.ini');
 if UpperCase(Copy(sl[0], 1, 5)) = '{C/S}' then begin
  edbParams.IsRemote := True;
  edbParams.ConfigPath := Copy(sl[0], 1 + Pos('}', sl[0]), MaxInt);
  cFound := True;
 end else begin
  cFound := FileExists(IncludeTrailingPathDelimiter(sl[0]) + 'EDBConfig.EDBCfg');
  if cFound then edbParams.ConfigPath := IncludeTrailingPathDelimiter(sl[0]);
 end;
 sl.Free;
end else cFound := False;
{If can't find the ini file it MUST be F/S}
if (not edbParams.IsRemote) and (not cFound) then begin
 cFound := FileExists(aPath + 'EDBConfig.EDBCfg');
 if cFound then edbParams.ConfigPath := aPath;
end;
if not cFound then begin
 ConfigFinderForm := TConfigFinderForm.Create(nil);
 if ConfigFinderForm.ShowModal = mrOK then begin
  if ConfigFinderForm.PathFound <> '' then begin
   edbParams.ConfigPath := ConfigFinderForm.PathFound;
   cFound := True;
  end;
 end;
 ConfigFinderForm.Free;
 if cFound then begin
  sl := TStringList.Create;
  sl.Text := edbParams.ConfigPath;
  sl.SaveToFile(aPath + 'TfR.ini');
  sl.Free;
 end;
end;
if cFound then begin
 Application.Initialize;
 dm := Tdm.Create(Application);
 aPath := '';
 LogonForm := TLogonForm.Create(Application);
 LogonForm.Simple := False;
 if LogonForm.ShowModal = mrOK then begin
  LogonForm.Free;
  SplashForm := TSplashForm.Create(nil);
  SplashForm.SplashMsg.Caption := 'Initialising';
  SplashForm.Show;
  SplashForm.Update;
  Sleep(250);
  try
   Application.CreateForm(Tlu, lu);
   Application.CreateForm(Tcs, cs);
   Application.CreateForm(TMainForm, MainForm);
  finally
   HideSplashScreen;
  end;
 end;
 Application.Run;
 SplashForm.Free;
end else nlhMessageDlg('The main configuration file is missing. Please contact the system administrator.')




Roy Lambert

Thanks Roy, I will study that.  

You are right, my present code includes a simple 'server' discovery
procedure.
By default app will start up and connect to its local database.

I provide a 'network' dialog (form) displaying useful info such as
hostname, ip adress and whether it is connected to the local or a
particular remote database.
The user 'in charge' will tick a box "Act as server" on the 'master'
host.
Then from any other instance a user may select an option to "Find
Servers" which broadcasts a UDP message 'Anybody out there?', and any
instance which has been flagged as a server will reply with its
\\hostname\share\ allowing the user to select and connect.

This I can easily adapt to provide the necessary details to change to a
server session.
But this requires the users to 'get it right'.  Still, they have
managed OK for many years .. so .. fingers crossed.

So, I may go with booting to an etLocal Session and leave it to the
users to fire up a server when appropriate and then help them to switch
to it.  Hmm..

Malcolm

Malcolm,

In addition to what Roy already said, there might be other issues.
Not about if it works or not - it will work, but some things that are fast with FS mode might be slow as a snail with CS mode, and the other way round too. But, that's a second step, I think. We can talk about that later.


--
Fernando Dias
[Team Elevate]

Fernando


>In addition to what Roy already said, there might be other issues.
>Not about if it works or not - it will work, but some things that are fast with FS mode might be slow as a snail with CS mode, and the other way round too. But, that's a second step, I think. We can talk about that later.

I did a lot of testing with speeds between c/s & f/s. It was a "chatty" app and speeds weren't much different either way - f/s was a bit faster sometimes and c/s faster others. The real difference would come if there were a lot of computationally intensive tasks hitting the server simultaneously. That could slow things down a bit especially on an underpowered server, but from what Malcolm has said about his app in the past I don't think that's liable to happen.

Roy

Fernando Dias wrote:

> Malcolm,
>
> In addition to what Roy already said, there might be other issues.
> Not about if it works or not - it will work, but some things that are
> fast with FS mode might be slow as a snail with CS mode, and the
> other way round too. But, that's a second step, I think. We can talk
> about that later.

Thanks Fernando.

At least I will not be accessing the data over the Internet.  

I am aware that there are some operations that will run better 'on the
server' as remote functions or procedures.
But I assume they will 'require' the server, so what happens on a
stand-alone machine?
Will the server load tcpip, or will it simply be unavailable in that
configuration?
Or have I got that all wrong.  :/

Still, the application is not very busy.  Under f/s the network traffic
hardly registers .. but there are a few procedures that can take 5-10
seconds (eg generating a 50 page report).

Malcolm

Malcolm,

<< In the first two of the above it will be single instance of the app so the Engine could be etLocal with no DBServer.  But if a stand alone laptop (no LAN) can still use the Server it may be convenient for me (or the user) to fire up the Server anyway, if necessary, so that I do not need to change the Engine's type.  I could do with some clarification on this point. >>

The best way to handle this is to run the EDB Server separately, and have all instances of the application use remote sessions to access the database(s) via the EDB Server.  This will require that the EDB Server always be running on one machine (and only one machine), so running the EDB Server as a service will be the best way to handle this.  The database(s) will be stored locally on the machine that is running the EDB Server, so you will want to make sure that the machine in question has proper backups/UPS, etc. to minimize the chance of corruption.

<< there may be port issues or the like, or is the IP address the key? >>

You can use the IP address of the EDB Server or the machine name.  It's usually easier to use the machine name because you can just tell users to execute this from the command line on the target machine:

hostname

to retrieve the machine's host name.

<< * provide a simple means for each instance of the application to be connected to the server (hmm, I seem to remember an NG message from Tim about providing a means to 'discover' a server on a LAN - did that ever happen)? >>

I abandoned that effort after SQL Server started experiencing issues with denial-of-service attacks on its server browser component.  It's more secure to simply require the connecting session to know the host name/IP address.

Tim Young
Elevate Software
www.elevatesoft.com

Malcolm,

<< But I assume they will 'require' the server, so what happens on a stand-alone machine? >>

On a stand-alone machine, you have two options:

1) Go ahead and run the EDB Server as a service, and have your application continue to use remote sessions.

2) Allow your application to operate in "single-user mode", whereby it switches to using local sessions that directly access the configuration/databases.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Malcolm,
>
> << But I assume they will 'require' the server, so what happens on a
> stand-alone machine? >>
>
> On a stand-alone machine, you have two options:
>
> 1) Go ahead and run the EDB Server as a service, and have your
> application continue to use remote sessions.
>
> 2) Allow your application to operate in "single-user mode", whereby
> it switches to using local sessions that directly access the
> configuration/databases.
>
> Tim Young
> Elevate Software
> www.elevatesoft.com

Using remote sessions all the time sounds like the simple option.

Tim Young [Elevate Software] wrote:

> Malcolm,
>
> This will require that the EDB
> Server always be running on one machine (and only one machine), so
> running the EDB Server as a service will be the best way to handle
> this.  

Is there a particular reason for running on 'only one machine'?  Or is
it just to avoid possible confusion?

>
> I abandoned that effort after SQL Server started experiencing issues
> with denial-of-service attacks on its server browser component.  It's
> more secure to simply require the connecting session to know the host
> name/IP address.

Noted

>
> Tim Young
> Elevate Software
> www.elevatesoft.com