Hello

I am experienced with applications where each workstation has its own executable file, and the database existed on a 'server'. Upgrading each workstation involved a loader app that ran before the main executable, and checked for an exe upgrade. If necessary, it copied the new exe from the download location, then copied the new exe and ran it.

It was all pretty cumbersome, but is it a better idea to just use a shortcut to the server based program file? That would cut out the slow copying of large program files to the workstation, but I am not sure how multiple instances of the program file would behave.

Things such as individual INI files, and printer paths, which sometimes must be relative to the workstation, concern me.

Also, does EDB have any facility for returning server details - such as database size, disk free space, path etc?

Also, has anyone heard any whispers on version 3?

Whew!

Regards

Peter

On 11/20/2014 9:11 PM, Peter wrote:
> It was all pretty cumbersome, but is it a better idea to just use a shortcut to the server based program file? That would cut out the slow copying of large program files to the workstation, but I am not sure how multiple instances of the program file would behave.

Multiple instances should behave just fine (assuming you don't do any
"weird" stuff with the exe like writing to it or such - treat it as
read-only file and you're generally ok).

They still need to load the file over network when it's run so there
might be increased latency on exe starting.

Once issue we found was that you have to kick everybody off to upgrade -
not a major issue but something to consider if your users are fond of
locking their machine with app running overnight.

This "leaving app running" and "running from network share" canm
sometimes result in some weird error messages since OS is unable to
access exe segment so teach users to just close it and restart it with
any issues.

> Things such as individual INI files, and printer paths, which sometimes must be relative to the workstation, concern me.

They should be stored with the workstation or even per user for this to
work properly. We have a "master" ini on central share with exe
(read-only) and per-user ini on user folder.

> Also, does EDB have any facility for returning server details - such as database size, disk free space, path etc?

No for most of these (db size i believe you can) but you can relatively
easily write a custom module to do that. Path -?! - if you mean server
file  path then that would usually be different than UNC path clients
need to use so store it in a config table of your own.

> Also, has anyone heard any whispers on version 3?

Nope - last i recall Tim saying is that he will work on it after EWB 2.x
ships so my crystal ball tells me later in 2015 sometimes would be earliest.

Raul

Peter

Raul has already covered most points, but I thought I would add my voice as a positive reinforcement for this way of working.

>> is it a better idea to just use a shortcut to the server based program file?

This is exactly what I do with all my applications. It works very well.

>>but I am not sure how multiple instances of the program file would behave.

The whole EXE has to be loaded over the network, which can take a few seconds with a slower LAN, but after that there are no further issues.

>>Things such as individual INI files, and printer paths,
>>which sometimes must be relative to the workstation, concern me.

On each machine when you create the shortcut you can tell Windows where to run the instance. This folder is used for the Ini files etc.

I have a Server Folder for all report-termplate-files. This is a folder which is public on the network and has a public folder-name similar to "\\Server\Reports" I can pass this path-name into my reporting tool (FastReports) reliably, provided that the folder name is not messed up.


Hope this is useful.

Adam

Adam


>The whole EXE has to be loaded over the network, which can take a few seconds with a slower LAN, but after that there are no further issues.

I about 50% agree with you, and for small exes that's probably waht will happen, but with larger ones Windows can decide to page a chunk out of memory (I don't know why) and then will need to reload over the LAN.

I don't have experience of it, but if you want to go down the route of a central exe you may want to consider something like UPX. One it make the exe size smaller so it loads faster across the LAN and second because of what it does Windows is pretty much forced to hold the whole program in memory so no paging.



Roy

Raul


>Once issue we found was that you have to kick everybody off to upgrade -
>not a major issue but something to consider if your users are fond of
>locking their machine with app running overnight.

Rebooting the server generally takes care of that <VBG>

Roy Lambert

Peter


If you don't have a users table for the application, and you don't use the users capability in ElevateDB then it would be a good idea to do so. You could also have a computers table. The reason I suggest the latter is that often per user settings mean per computer settings and I HATE using the registry although you could do so.

I'm still using a copy of the program on each computer, mainly for speed purposes. I have a config table which has defaults and company level settings and a staff table part of which are the user overrides. The advantage is that even if people move around computers their personal settings go with them.

My staff table holds quite a bit

CREATE TABLE "Staff"
(
"_ID" VARCHAR(5) COLLATE "ANSI_CI",
"_Name" VARCHAR(60) COLLATE "ANSI_CI",
"_Title" VARCHAR(40) COLLATE "ANSI_CI",
"_DirectDial" VARCHAR(25) COLLATE "ANSI_CI",
"_fkemAddress" VARCHAR(60) COLLATE "ANSI_CI",
"_Sig" INTEGER,
"_fkProjects" INTEGER,
"_CheckDate" DATE,
"_SUOP" VARCHAR(11) COLLATE "ANSI_CI",
"_VP" VARCHAR(11) COLLATE "ANSI_CI",
"_Privileged" BOOLEAN DEFAULT FALSE,
"_Permitted" BOOLEAN DEFAULT FALSE,
"_Group" VARCHAR(15) COLLATE "ANSI_CI",
"_ColourScheme" VARCHAR(30) COLLATE "ANSI_CI",
"_Notes" CLOB COLLATE "ANSI_CI" COMPRESSION 6,
"_FilterStore" BLOB COMPRESSION 6,
"_AutoLoads" CLOB COLLATE "ANSI_CI" COMPRESSION 6,
"_Tasks" CLOB COLLATE "ANSI_CI" COMPRESSION 6,
"_UserOptions" CLOB COLLATE "ANSI_CI" COMPRESSION 6,
"_StatsDisplay" CLOB COLLATE "ANSI_CI" COMPRESSION 6,
"_SpeedDials" CLOB COLLATE "ANSI_CI" COMPRESSION 6,
"_FavouriteCompanies" CLOB COLLATE "ANSI_CI" COMPRESSION 6,
"_FavouriteContacts" CLOB COLLATE "ANSI_CI" COMPRESSION 6,
"_FavouriteProjects" CLOB COLLATE "ANSI_CI" COMPRESSION 6,
CONSTRAINT "PK" PRIMARY KEY ("_ID")
)

otherwise I'd use the description or attributes in Tim's users table

Roy Lambert

Den 21.11.2014 05:41, skrev Raul:
>...
> Once issue we found was that you have to kick everybody off to upgrade -
> not a major issue but something to consider if your users are fond of
> locking their machine with app running overnight.
>
> ...

You can avoid this by using a "stub" and keeping a few versions of the
exe file.

Let's say you have a program named MYPROG.  Rename new versions as you
create them to e.g.
MYPROG_20141101a.exe
MYPROG_20141112a.exe
MYPROG_20141112b.exe
and create a "stub" - MYPROG.exe - which just loads the latest version
of the exe files with names starting with MYPROG (its own name, really -
which is convenient if you choose to use this with several programs in
the same folder).

You'll then have (f.ex.):
MYPROG.exe
MYPROG_20141101a.exe
MYPROG_20141112a.exe
MYPROG_20141112b.exe
(The last part of the names can be anything, as long as they differ).

Your next version could be MYPROG_20141122a.exe.
When the next user starts the program, he really starts the stub
(MYPROG.exe) which then finds and starts the latest and greatest.
Active users will continue to use the "old" version until they exit and
start the program again.
Usually, by the next day everyone will be using the latest version, and
you can delete one or more of the old ones.
Moreoever, if the latest version was a dud you can delete it and users
will revert to the previous version as they restart MYPROG.exe.

I've used this for more than ten years.  The programs reside on the file
server and users have a shortcut on their desktop (to MYPROG.exe).

--
Aage J.
ps
I can post the source code (less than 70 lines).  It can be used as a
stub for any program just by changing its name.

Aage J.,

This looks promising. But why can't the user run a batch file on the server to point to the correct "MYPROG_20141122a.exe" program?

Barry

Aage


Nice approach and I for one think you should post the source to the binaries.

Roy Lambert

Den 23.11.2014 06:20, skrev Barry:
> Aage J.,
>
> This looks promising. But why can't the user run a batch file on the server to point to the correct "MYPROG_20141122a.exe" program?
>
> Barry
>

You can, but you would have to change the batch file whenever you have a
new version of MYPROG.

--
Aage J.