Hi

I have been developing a Client Server App for one of my clients for 4 years.

DBISAM has been putting the food on the table in my house with this app since 2005 -
thanks Tim!

The app executable is sitting on a Win2003 server with the Server Engine.  The users each
have a shortcut to the executable on the server on their desktop.

This was initially done during development for convenience, and as it works, we left it.
The executable is 5mb and as we are running Gigabit Lan it loads fast.

The big advantage is that upgrades are easy, I just FTP new executables etc onto the
server, instead of upgrading each PC (30 of them).  

I have two questions.

I dont fully understand what happens when you run an app like this. The executable
residing on a remote machine.  It obviously runs in the memory on the local machine.  

1) What I would like to know is - Is there any load created on the server by running an
app like this? (once the app has been loaded into memory on the client machine).

2) Once the App is loaded and running does the app itself count as a connection as the
file is effectively open read only?

The reason I ask is that I want to move the DBISAM Server off the Win 2003 server onto an
XPPro server to reduce the load on the Win2003 Server.  I know that the TCPIP DBISAM
connections are not limited but that 'File' connections are limited to 10 computers.

My client is struggling a bit in the recession and I am trying to help out.  They need to
lighten up their server but have a tight budget and dont afford the Win Server 2003
licenses ($4000) for a new one.

Thanks for any assistance

Regards

Peter

"Peter H" <peter.hodgson@software4biz.co.uk> wrote in message
news:4B3C5C2F-BD32-445D-892F-DBC0F9FCE198@news.elevatesoft.com...
>
> My client is struggling a bit in the recession and I am trying to help
> out.  They need to
> lighten up their server but have a tight budget and dont afford the Win
> Server 2003
> licenses ($4000) for a new one.
>

Pricey, I ran SnugServer on an XPPro box for over 2 years without any
crashes.
The most online was 35 on Royal Ascot race day. It was an IW app and it was
using a DBIsam server that had a potential 175 users but they never all
logged on
together. I think its around 39 euros find out about how many uses can logon
for
file server tho they dont mention it on their site.
www.snugserver.com
HTH
Rita

Peter,

<< DBISAM has been putting the food on the table in my house with this app
since 2005 - thanks Tim! >>

No, thank *you*.  Your use of DBISAM has been putting on the table in my
house since 2005.

<< 1) What I would like to know is - Is there any load created on the server
by running an app like this? (once the app has been loaded into memory on
the client machine). >>

If the .exe needs to be paged in and out from disk on-demand, then yes, this
would create some load on the file server.   Opportunistic locking may help
with this a bit, but I'll have to double-check on this.  Op-locks allow the
client OS to buffer portions of a file locally on the client machine because
the file's status is such that the client OS knows that another client
cannot write to the file, and this is the case with .exe files.

<< 2) Once the App is loaded and running does the app itself count as a
connection as the file is effectively open read only? >>

For Windows, yes.   Any connection to the file server for the purposes of
opening up a shared resource counts as a connection.

<< My client is struggling a bit in the recession and I am trying to help
out.  They need to lighten up their server but have a tight budget and dont
afford the Win Server 2003 licenses ($4000) for a new one. >>

If you're already accessing the data on a shared resource on the file
server, then it really doesn't matter in terms of the number of connections
if you also open the .exe in a shared manner.  So, short of switching to
using the DBISAM Database Server instead, there really isn't any way to
reduce the number of file server connections and/or load.

One thing to keep in mind, however:

If you do switch to using the DBISAM Database Server, you can write a
server-side procedure that checks for a new version of the .exe and
automatically downloads it to the user's computer.   If you want more
information on how to do this, just let me know.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:37CBE8F4-8016-426F-A2CA-4F5892A6C3E2@news.elevatesoft.com...

So Tim if I have a remote DBISam server like I have,
it could handle lots more connections from local machines
like I do than a Win2003 licence allows ?
Then if thats true then any Socket server app like IW could
circumvent MS software licence legally. I never ever really
thought hard on that one just sorta hoped and prayed it all
just worked. Divine providence stepped in and saved my
rear as they have been paging your server and not windows.
Going off sulking now as I never gave a thought to this in
early days with the DBSrv grrrrrrrrrrrrr.
Rita

Hi Tim

Thanks for the info.

I am running the DBISAM Server V4.  I dont have the source so I guess I cant add a server
side procedure.

I am going to move the executables on to the client machines.

I have a plan to build a small app that shells the actual executable on the client so that
I can check for a new executable on the server when the user opens the program.

If there is a newer executable I will do an automatic upgrade by copying the new
executable onto the client.

The app will then shell the executable and close.

If there is no newer version the app will simply shell the executable and close.

Thanks again

Regards

Peter   


"Tim Young [Elevate Software]" wrote:

Peter,

<< DBISAM has been putting the food on the table in my house with this app
since 2005 - thanks Tim! >>

No, thank *you*.  Your use of DBISAM has been putting on the table in my
house since 2005.

<< 1) What I would like to know is - Is there any load created on the server
by running an app like this? (once the app has been loaded into memory on
the client machine). >>

If the .exe needs to be paged in and out from disk on-demand, then yes, this
would create some load on the file server.   Opportunistic locking may help
with this a bit, but I'll have to double-check on this.  Op-locks allow the
client OS to buffer portions of a file locally on the client machine because
the file's status is such that the client OS knows that another client
cannot write to the file, and this is the case with .exe files.

<< 2) Once the App is loaded and running does the app itself count as a
connection as the file is effectively open read only? >>

For Windows, yes.   Any connection to the file server for the purposes of
opening up a shared resource counts as a connection.

<< My client is struggling a bit in the recession and I am trying to help
out.  They need to lighten up their server but have a tight budget and dont
afford the Win Server 2003 licenses ($4000) for a new one. >>

If you're already accessing the data on a shared resource on the file
server, then it really doesn't matter in terms of the number of connections
if you also open the .exe in a shared manner.  So, short of switching to
using the DBISAM Database Server instead, there really isn't any way to
reduce the number of file server connections and/or load.

One thing to keep in mind, however:

If you do switch to using the DBISAM Database Server, you can write a
server-side procedure that checks for a new version of the .exe and
automatically downloads it to the user's computer.   If you want more
information on how to do this, just let me know.

--
Tim Young
Elevate Software
www.elevatesoft.com

Rita,

<< So Tim if I have a remote DBISam server like I have, it could handle lots
more connections from local machines
like I do than a Win2003 licence allows ? >>

Sure, but remember that these are only DBISAM connections, not full-blown
resource sharing connections.

<< Then if thats true then any Socket server app like IW could circumvent MS
software licence legally. >>

Well, sure, if the socket server application provides all of the
file-sharing and resource-sharing protocols that the MS OS provides.

--
Tim Young
Elevate Software
www.elevatesoft.com

Peter,

<< I am running the DBISAM Server V4.  I dont have the source so I guess I
cant add a server side procedure. >>

Sure you can.   We provide the source to the dbsrvr.dpr project in the
\servers\dbsrvr\source directory under the main installation directory.

<< I am going to move the executables on to the client machines.

I have a plan to build a small app that shells the actual executable on the
client so that I can check for a new executable on the server when the user
opens the program.

If there is a newer executable I will do an automatic upgrade by copying
the new executable onto the client.

The app will then shell the executable and close.

If there is no newer version the app will simply shell the executable and
close. >>

That will work fine, but you can also just use the DBISAM Database Server
for all of that and avoid any direct interaction with the file server.  I
recently gave this information to another customer that requested it:

What you would do is set up a server-side procedure that accepts
date/time/size parameters from the client and returns a status (Boolean,
Integer) about the presence of a newer version of the .exe in a directory on
the server machine where the DBISAM Database Server is running.  If the
status is "newer", then you can have a different server-side procedure that
simply downloads the .exe to the client by putting it in a return parameter.
You can see how this is done with a text file here in the manual:

http://www.elevatesoft.com/manual?action=mantopic&id=dbisam4&product=d&version=7&category=1&topic=8

under "Server Procedures".  You would use the TDBISAMParam.SaveToFile method
to save the result parameter containing the .exe contents to a file on the
client machine with the extension of .new.  You can see how to call a
server-side procedure here:

http://www.elevatesoft.com/manual?action=mantopic&id=dbisam4&product=d&version=7&category=1&topic=10

Once the .exe is on the client, then the same process for updating .exes
would be in play.  Namely, you would need a launcher .exe for your main
..exe, and then just have the launcher .exe look for the presence of your
main .exe with an extension of .new, which would be the new version of the
..exe that was just downloaded from the server-side procedure.  If a .new
version is found, then the launcher will rename the existing .exe so that it
has the extension of .old, and then rename the .new to .old so that it is
now the main .exe.  Then it will launch it and everything proceeds as
normal.  You should probably also throw up some dialog boxes during this
whole process.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:60AE2511-8DCA-4022-AF70-E0B7A2C76B73@news.elevatesoft.com...
> Peter,

I still don't see the problem with just running the executable off the
server. Can anybody explain?

Robert

Hello Robert,

> I still don't see the problem with just running the executable off the
> server. Can anybody explain?

Performance ... Running an executable from the server is slower than
running locally ...

In our days disk space isn't expensive and i find it stupid to do that.

Also if someone or something for any reason corrupts the executable
on the server Boom! All clients went down.

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

You can but need a client license (CAL) for every user (or at least license
for concurrent connection - whatever makes more sense in your scenario).
Using XP Pro that Peter wants to use you will likely run into the connection
limits as well.

Both above apply in this case since you're using a windows os server
file-share for accessing the exe (even though you are using just TCP sockets
with DBISAM server for data).

Raul


"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message
news:EEBF7968-FA33-4AAF-964F-9470171C3B6E@news.elevatesoft.com...
>
> "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
> news:60AE2511-8DCA-4022-AF70-E0B7A2C76B73@news.elevatesoft.com...
>> Peter,
>
> I still don't see the problem with just running the executable off the
> server. Can anybody explain?
>
> Robert
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4292 (20090730) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4292 (20090730) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com