Ah. So that's what that setting does. Sweet.

Jeff,

<< Ah. So that's what that setting does. Sweet. >>

The "Server Name" setting ?  Yep.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

I wanna suggest some possible enhancement for ElevateDB (server).

I've noticed that the EDBServer is auto-creating an .ini file in the <drive>\ProgramData\ElevateDB** folder with exactly the same name as the EDBServer's executable name, right?

When (as my colleague mentioned before) you have an situation which requires multiple EDBServer running on the same machine you'll have some manual configuration to do. eg: As far as i understand you can 'rename' the EDBServer's executable name, so then there will be a new .ini file created so you can re-config the server with its own settings (and different port off-course).

There is one great downside to this solution (read: for us!) when the customer is update-ing our software via an Setup (Inno) then the renamed EDBServer will *NOT* being updated!, this because the filename is not known by the setup. This 'problem' we've experienced in the beginning also with our other database vendor (NexusDB). They have an very nice solution for this 'problem'. I'm trying to describe here how they solved it, also pasting some code from out setup so you can take a look of it (if you want). Our setup is also using the same logic as Nexus.

------------------------------------------------------------------------------------------------------------
Nexus's Solution:
------------------------------------------------------------------------------------------------------------
When the nexusdb server is started it also create an kind of .ini file, this file is also using the server's executable name for the filename (the same as you do) but... they put the file in and 'special' encoded folder (two levels deeper than ElevateDB). This 'special' encoded folder contains the file path where the nexusdb is started from, in this way you can put the nexusdb server in several folders and they all have their own .ini / settings file (which is located on different special encoded paths). In this way you avoid the update problem when an customer is updating the software. An extra benefit is that you always can see what the location is where the nexusdb server is running from.
PS. Nexus is also used the different path's as Elevate does under the different OS's, XP/W2K3 & Vista/Win7/W2K8/W2K11.

------------------------------------------------------------------------------------------------------------
Code used in our setup to encode path: (copy paste from our inno setup pascal script environment)
------------------------------------------------------------------------------------------------------------
const
 { PathEncode }
 UNSAFE_CHARS         = '\:*#%<>+[] '; { do not localize } //  UnsafeChars = array of char = ['\', ':', '*', '#', '%', '<', '>', '+', ' ','[',']'];  {do not localize}

function CharIsInSet(aString: string; aCharPos: Integer; aSet: string): Boolean;
begin
 if aCharPos > Length(aString) then
   Result := False
 else
   Result := (Pos(String(aString[aCharPos])[1], aSet) > 0);
end;

function PathEncode(aPath: string): string;
var
 i: Integer;
begin
 Result := ''; { do not Localize }
 for i := 1 to Length(aPath) do
 begin
   if (CharIsInSet(aPath, i, UNSAFE_CHARS)) or (aPath[i] >= #$80) or (aPath[i] < #32) then
     Result := Result + '%' + IntToHex(Ord(aPath[i]), 2)  { do not localize }
   else
     Result := Result + aPath[i];
 end;
end;

function GetNxConfigPath(Param: String): string;
begin
 if OSIsWindowsVistaOrBetter then
 begin
   { configpath OS >= Vista eg: C:\ProgramData\NexusDB2\nxServer\C%3A%5CUsers%5CPublic%5CDocuments%5CEnk%20Software%20Db%5C }
   Result := ExpandConstant('{commonappdata}') + AddBackslash(ExpandConstant('{#ddNxServerCfg}'));
   Result := Result + PathEncode(AddBackslash(GetEnkDbPath(Param)));
 end
 else begin
   { configpath OS < Vista eg: equal to EnkDbPath }
   Result := GetEnkDbPath(Param);
 end;
end;

------------------------------------------------------------------------------------------------------------
Screen-shot taken from my own machine, as you can see I've started nexus from a bunch different folders:
------------------------------------------------------------------------------------------------------------

**depending on the OS version, described here:
http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=Starting_Configuring_Server


My 2 Cents



With kind regards,

Richard Lichtendahl
ENK Software BV - The Netherlands, Europe (+1 GMT)

Richard,

<< There is one great downside to this solution (read: for us!) when the
customer is update-ing our software via an Setup (Inno) then the renamed
EDBServer will *NOT* being updated!, this because the filename is not known
by the setup.

This 'problem' we've experienced in the beginning also with our other
database vendor (NexusDB). They have an very nice solution for this
'problem'. I'm trying to describe here how they solved it, also pasting some
code from out setup so you can take a look of it (if you want). Our setup is
also using the same logic as Nexus. >>

Thanks, I'll see what I can do for the next build.  I probably won't adopt
their approach, but rather allow one to specify the .ini file name/location
in some fashion.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

<<Thanks, I'll see what I can do for the next build.  I probably won't adopt
their approach, but rather allow one to specify the .ini file name/location
in some fashion.>>

Great, thanks.


Just out of curiosity.
You mentioned you won't adopt their approach, is there an particular reason for? is their approach wrong or have it some downsides? One advantage about their approach (OK, thats my personal opinion) is that you never have to worry about passing an filename/location as parameter to the executable so the server knows where to find it's own .ini. Especially in the service part, the services can be registered on same old manner without worrying about the extra parameter.  



With kind regards,

Richard Lichtendahl
ENK Software BV - The Netherlands, Europe (+1 GMT)

Richard,

<< You mentioned you won't adopt their approach, is there an particular
reason for? >>

I don't like to litter people's systems with meaningless (to them) folders.
Just my opinion and development philosophy, not a knock on NexusDB.

--
Tim Young
Elevate Software
www.elevatesoft.com