ElevateDB is a great database engine and I love it. I have about 30-40 clients using C/S applications using EDB and by the end of the year this number is going to be more than 120. What worries me most is that EDB has many new releases (which is good) and periodically I would like to upgrade those clients.

I though of some ways to make the upgrade as easy as possible, including developing a small application that will connect to a remote edbsrvr at my site, download the upgrade using edb stores, stop the service, install (copy) the new edbsrvr and start the service again.

Yet, I would like to listen to your suggested practices in order to do so before starting developing anything. I guess many have the same concerns and we would all benefit by this.

You are right that many of us can gain from sharing best practice on this, of course each developer needs slightly different things.

The first risk / issue is having EXE built with EDB version 3.10 while SRVR is on version 3.11 or 3.09 etc.

There have been cases where a mismatch between versions of the EDB components in your application code & the SRVR code have caused problems.

Therefore any strategy for remote update really needs to touch the EXE & SRVR, or at least be able to check that the EXE EDB version is OK.

--

My own strategy (after a few years of fiddling) is to put my EXE on the server only. Usually I have a folder MyEDBApp & in this the EXE + some support & config files, then folders for data, reports, back up.

Clients just have a short-cut on their desktop pointing to the EXE. There are no files installed on any client machine, which makes life easy ... but clients have to have access to the server folder, so it has to be shared (some security risk). Note that I don't share the data folders, or the folders containing the SRVR ... the EXE accesses the data through the SRVR over IP, so only 1 server folder is shared.

Thus I can switch off the SRVR, delete & replace the EXE, SRVR & update any Data files all from 1 place. As soon as it is finished I switch the SRVR back on & it should work.

--

I don't yet use this strategy remotely ... it seems a bit too risky, as each of my customers' systems is quite bespoke & each has a lot of custom-code, so I like to be on-site to test & check things.

However if you have a uniform code-base / application which is going to all the different customers then the strategy you suggest might work, so long as you bear in mind the issue of matching the EXE EDB components with the SRVR.

Adam, you are totally right about your concerns. These are my concerns also, that's why I wanted to open start a Thread here, as this is going to be one of the major issues we are going to face in the future.

My thought, which is a bit complicate is as below.

Having a C/S application, that means that you have to site to update actually. So, the whole thing should be in two parts. On the server site an application should be liable to update the server database engine, while the same time it will download and make available the client update, setting a flag for the client to do the update. On the client site an update application should transfer the update and install it.

This is the idea as I figured it in my mind, yet it is too complicated and I think it is not the best practice. I did not mention it before so that I could receive new ideas without directing people to a specific solution.

I think this is a nice thread for everyone to post to, but mainly I would like to listen to elevatesoft team and there ideas, or maybe future plans regarding this.

Georgios,

<< Having a C/S application, that means that you have to site to update
actually. So, the whole thing should be in two parts. On the server site an
application should be liable to update the server database engine, while the
same time it will download and make available the client update, setting a
flag for the client to do the update. On the client site an update
application should transfer the update and install it. >>

The stores functionality in EDB can do all of this for you:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=Stores

Actually, what you can do is just have them update the server and then copy
a new version of the client application to a directory on the server machine
that is also the path for a local store defined on the EDB Server.

In the client application, have the application check for the existence of a
new version of the client application in the local store on the EDB Server
as the first thing that occurs during startup.  It can do so by using this
statement:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=SET_FILES_STORE

and then querying this table:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=Files_Table

for the latest creation date (or you could use a special naming convention
for the .exes, like myapp_202.exe, for example).

If it finds a new version, it can then copy the new .exe to the local
machine using this method:

http://www.elevatesoft.com/manual?action=viewmethod&id=edb2&product=delphi&version=7&comp=TEDBSession&method=SaveStoreFileToStream

and save it as something like myapp.exe.new (just an example).  Then inform
the user that the client application will now need to close and be restarted
so that the update can complete.

Finally, use a loader application with your client application that simply
checks for a new version of the .exe in the client application directory
(the myapp.exe.new file) and, if it exists, copies it over the existing
client application and deletes it, before proceeding with launching the new
application.

I'll see if I can put something up as a technical article with more details
after I'm done with the DBISAM releases for XE2.

--
Tim Young
Elevate Software
www.elevatesoft.com