Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 14 total |
Running an executable over the network |
Wed, Jul 29 2009 6:25 AM | Permanent Link |
Peter H | 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 |
Wed, Jul 29 2009 11:06 AM | Permanent Link |
"Rita" | "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 |
Wed, Jul 29 2009 11:57 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, Jul 29 2009 12:38 PM | Permanent Link |
"Rita" | "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 |
Thu, Jul 30 2009 6:08 AM | Permanent Link |
Peter H | 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 |
Thu, Jul 30 2009 1:06 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Thu, Jul 30 2009 1:07 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Thu, Jul 30 2009 4:12 PM | Permanent Link |
"Robert" | "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 |
Thu, Jul 30 2009 6:41 PM | Permanent Link |
Charalampos Michael | 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 |
Thu, Jul 30 2009 8:57 PM | Permanent Link |
"Raul" | 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 |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Monday, June 17, 2024 at 07:11 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |