Hi Team,
Only having a limited experience with using EDBServer and then on a Network Server.
I am debating whether to set up a single PC, not networked, Customer with EDBServer.
What are the Pros & Cons of using EDBServer on a single user/PC?
Any caveats?

Regards & TIA,
Ian

Ian


Pro: its a server and has those benefits - limited in this case because if the "client" crashes so does the "server"

Con: its an extra layer of complexity that isn't needed, its taking up more of the PCs resources for the same job (probably not enough to bother with)

ElevateDB is easy to switch between f/s and c/s modes -in my case it takes one ini file - the first line determines f/s vs c/s and gives the path etc plus a small procedure called from the datamodules create event.

I moved loading the ini to the dpr so I could bomb if the ini file didn't exist but it could easily be loaded in the procedure below. I also created a record to hold various parameters but a variable would do just as well

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;



Loading the ini file

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


type
TedbParams = record
 IsRemote: boolean;
 ConfigPath: string;
 Encryption: string;
 Sig: string;
 Password: string;
 TempPath: string;
 UserID: string;
end;


Roy Lambert

On 11/18/2019 3:37 AM, Roy Lambert wrote:
>
> Pro: its a server and has those benefits - limited in this case because if the "client" crashes so does the "server"
>
> Con: its an extra layer of complexity that isn't needed, its taking up more of the PCs resources for the same job (probably not enough to bother with)
>

To add to Roy's already good list there are few more potential pros
(IMHO) - you have to asses value in your case and whether you prefer to
handle most of these things in your app instead

1. Easier to use  global buffered file I/O

2. (Possibly easier) automated backups and/or remote replication of data
(either on lan or back to you for example)

3. Potentially easier to do remote troubleshooting or data extract or
such - we have VPN access to customer sites and lot easier to just
connect to EDB server to do or look at something that doing screen share
every time


And a con :

It will require bit more thoughtful setup and app has to deal with edb
remote session errors and reconnect logic and such

Raul

Raul

Very good points - my take on them


>1. Easier to use global buffered file I/O

That surprises me, but since I retired I don't use c/s so can't really comment

>2. (Possibly easier) automated backups and/or remote replication of data
>(either on lan or back to you for example)

I would agree with you but for two possible facts. A server is (generally) just left running 24x7 (at least mine were) a single users PC may well be turned off when finished with thus rendering automated backups moot. The second one depends on the installation - see below

I've done it both ways - my recruitment software when running on a server had a job that ran early in the morning when everyone was snoring. It was complicated by the fact that I also had an email server (and no it wasn't Outlook) integrated into the application that also ran 24x7 (almost). I had to code to suspend that activity whilst the backup was running which was a bit tricky.

For single user I like the prod-em approach (remind at logon / logoff) or the "its your problem if you don't but it'll help my bank balance" approach

>3. Potentially easier to do remote troubleshooting or data extract or
>such - we have VPN access to customer sites and lot easier to just
>connect to EDB server to do or look at something that doing screen share
>every time

I meant to add that but my memory is going

>And a con :
>
>It will require bit more thoughtful setup and app has to deal with edb
>remote session errors and reconnect logic and such

Fair point but I read it as a single user so I doubt this will really bite.

On 11/18/2019 9:28 AM, Roy Lambert wrote:

>> It will require bit more thoughtful setup and app has to deal with edb
>> remote session errors and reconnect logic and such
>
> Fair point but I read it as a single user so I doubt this will really bite.
>

This one is more around things like idle sessions timeout still might
apply in case of c/s.

Even using local loopback address i have seen windows do some funny
stuff with overall network up/down status when one is on wifi and might
move around office. And of course there is the sleep/wake reconnects.

In either case fix is simple but local session only app would never have
seen any of those callbacks/exceptions and just needs to handle them

Raul

Raul


>This one is more around things like idle sessions timeout still might
>apply in case of c/s.

Very good point

Roy

Roy, Raul,
Thank you both for your feedback.
Being 'Native' or C/S is only a matter of an Ini file and I have it in
place working in C/S mode.
It is all working fine, I was just curious as to any caveats I might
not be aware of.
One thing I am curious about is any relative performance experience you
may have seen between the two.
As a side issue I went C/S because the User said he was getting what he
described as a 'loss of tracking' betweenrelated tables in native mode
that he hasn't seen since gonig C/S.  He is running a Win 10 Home PC.
Thanks agan Guys,
Regards,
Ian

On 11/18/2019 1:43 PM, Ian Branch wrote:
> One thing I am curious about is any relative performance experience you
> may have seen between the two.

It depends on db access pattern by the app.

AFAIK local access (with exclusive open, if possible) is going to be the
absolute fastest since you still get disk caching - however one would
really only notice if you for example looped thru a big table and wanted
fastest speed.

If app has many DB lookups (for example combos/lists on forms) then
remote might be bit slower since there is a extra latency on network for
each query.


> As a side issue I went C/S because the User said he was getting what he
> described as a 'loss of tracking' betweenrelated tables in native mode
> that he hasn't seen since gonig C/S.  

Do you know what that means (is it something to do with master/detail
views or something else completely)?

In general there would be no EDB functionality differences i can think
of so could be something with the app !?

Raul

Ian


I'm with Raul on this. I did quite a bit of testing a while back (no longer have the results). A lot depends on your app, how "chatty" it is and wether you're using table or queries, network speed, and the power of the server.

What I found for my multi user "chatty" app was that C/S was more consistent but that F/S was faster for some operations even over the LAN with multi-user access. I made no attempt to split out the impact of UI (data bound controls) on speed since I was using the same UI for both scenarios.

Whilst I have often (since moving to ElevateDB) I often build the capability for C/S in I would normally configure a single user app as F/S.

Like Raul I would like to know what "loss of tracking' between related tables" means. My guess would be that you have multiple versions of a table and changes to one aren't reflected in the other until a refresh.

Roy Lambert

Roy, Raul,

The 'Loss of Tracking' was for the Detail records in Master/Detail relationships.
In one case, A 'Groups' master table, there are up to 40 detail tables.

The picture is as follows..
The Database is a Music Database cataloging Albums (Record, Tape, Cassette, CD, etc), Artists, Labels, Groups & Tracks.  So far.  It is evolving.
ATT there are some 7800 Albums, 3213 Artists, 176 Labels, 93 Groups & 125 Tracks.  It is very early days in the cataloging process.

For any given Music Group there may be up to 40, or more, different Artists over the Groups lifetime.
In the Groups table I have 40 SmallInt Artist fields, the Artist field links to and Artists table Integer Index field and shows the Artist's Name in the Groups Form.

Having the 40 fields & related Tables/Datasources is a pain in the proverbial and I am open to alternative techniques.

Regards,
Ian