Is there any way for SambaPOS to be run from a network share instead of being installed on a particular computer. Sure, I guess it would still have to save data in PrgramData and the current user’s documents, but having the core program files stored on one central file share location would make upgrades much easier.
If this is not possible, would it be possible to have a separate ‘upgrade’ relase packaged with an installer that does not include the sambled and Local DB installer files - Just the files neccessary in stall SambaPOS? This would speed up updating terminals with the latest releases.
No - SQLEXPRESS installed on a “server” computer doesn’t mean the the application itselt will run from a central point. As things stand, SambaPOS still needs to “installed” on each terminal. I wonder how necessary this is, or if a few changes could be made to allow it to run as a standalone app from a network share.
The problem I was hinting at with the upgrade is the adding the Local DB engine in the installation package increases the payload and wouldn’t be needed in multiple terminal deployments.
I remember those day when most program are standalone exe file. I use to run it from network drive.
But honestly I don’t think it save any resources (cpu or ram) except harddrive space.
That is not part of the installer is it? Does it not download the LocalDB installer package instead?
I get what you’re saying. Updating to latest requires installation on each Terminal, even if you only download the installer once and share it among machines. Running the application from a Network Share would require only a single upgrade install that applies to all local machines.
It’s not included in the installer package, it gets downloaded if you select it and not already installed (same as for the .NET Framework 4.5 prerequisite)
I don’t remember the specific error, but an error was thrown before it even loaded. I am not sure if it’s even possible - I was just floating it as an idea and I thought it might help to centralise the deployment. But I guess distributing the package and installing using powershell or something might be the more correct way forward.
For what I know, SambaPOS will store files elsewhere from just the Program Files folder. There are files stored in user profile (My Documents\SambaPOS5) as well as some files in C:\ProgramData.
What error did you get? Maybe you can post it here and we can see what might have caused it?
One issue I can see from that would be the loss of local program setting values.
Like those used for last bill and many automation flows where you want to run seperate flows per till rather than centralised…
These are not in the SQL say with a terminal prefix as far as I know.
That’s not to say you couldn’t not use local settings and use a terminal prefix in global getting a in the database without too much hastle but is a point that would be effected by a shared program.
I expect if you created alias/shortcuts to the apropeate folders on each machine you could probably get it to work.
Personally I have a shared folder for all machines on every setup for drivers and files etc and would just download to that and run on each machine.
For a production system it’s not like your going to be updating every few days or even weeks. Public stable releases are general several months between and unless you have 10’s or 100’s of tills on the setup it’s barely worth the hastle of setting it up to be shared in the first place.
Actually I don’t know where local program setting values are stored - are they just stored in memory? Are they saved to disk at all, if not in SQL? So can they survive if SambaPOS is closed and reopened?
Local Program Settings are stored in memory of the Terminal Computer. Closing SambaPOS will release that memory, so when you re-open, the Local Program Settings will be gone.
I don’t see this as an issue with a shared installation. Samba.Presentation.exe will not be aware that it has been run multiple times on different computers, and things stored in the User Profile should be fine as well.
The path I wonder about is ProgramData, since that is local to each machine (not user), and always resides on the OS drive (usually C), I think.
If an upgrade installation is run from one terminal, and the upgrade writes new or changed files to either ProgramData or User Profile, that is where the problem will arise, because only that machine will be modified/upgraded, and the other terminals will need to be upgraded as well.
Just shooting in the dark here since I am not at a Samba terminal to look closely at what those folders contain. I would simply just try it and see what happens. Check the file dates after an upgrade in those 2 folders to see if something changed compared to another terminal.
