V5 Check Database Version - not resolved by Mar 16 posting

I have three terminals installed at the site. Two are preventing me from logging in at any level with the message “Check Database Version Database: 125 - App:124”, the third terminal allows me to run the software as it is showing DB:125-125. This implies that the client database has gone backwards on the two terminals that were in operation

My problem is the main terminal with the database attached is one that will not allow me to log in.

All references I can see say “reinstall SambaPOS” - why, the system was working throughout the day and two terminals have decided to lock me out.

How can I resolve this before the start of tomorrow’s work period?

Ive changed to question as this isnt an issue

What you have done is try to open a database with a newer version of samba. Youll need to reinstall the older version that your database is compatible with and backup, then run the latest version installer and it should upgrade your database

Hey @RickH
This is one of our sites and nothing has been done with the software? The Operator just came in and found both terminals logged out?

With the Office Terminal working as that was not logged in why would the other two terminals fail? We are trying to backup on the 3rd but cannot create permissions or a backup.

I will get my college to paste the database backup name here. Emre this just looks weird…

Back up error

###First question:

125 update contains Department support for Account Transactions.


That won’t happen by itself. Third (working) terminal is 5.1.61 version. Other terminals are probably 5.1.60.

###Second Question:

Is says operating system can’t find a path named O:\. Do you have O drive?

1 Like

V5.1.61 is still in beta right? So I now discussing with my TEAM! how the hell this happened?

So @emre can other terminals still run once the V5.1.61 was installed on the 3rd machine as they were not logged out since 22/12/2016. A power failure seems to have logged them out and then they would not run?

Yes we did just trying to backup on the 3rd terminal but can not get past permissions - tried adding:

to the default directory but it says the object cannot be found?

ANYWAY: Emre can I assume if we use Management Studio to make the backup (Full) that will be fine as a backup before we upgrade the other two terminals.

What you need to know about backing up.

  1. SambaPOS creates backup by running an SQL script. This is similar to what Management Studio does but SambaPOS does some additional stuff to maintain backups.
  2. So backup files generates on server. It won’t create a backup to a pen drive connected to a terminal. You need to configure backup location related to PC that runs the SQL server.
  3. Permission relates with the user account that runs the SQL Server service. The easiest way to solve this is defining backup location as the SQL Server’s default backup folder. If you need to backup somewhere else you need to be sure user that runs the SQL Server service have permission to access that location.

So backing up with Management Studio will also work but using SambaPOS Backup tool is recommended.

PS: Default backup folder for my current PC is C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Backup\. Your backup location might be different depending on your installation.


Just to be clear what @RickH said is correct. What happened is that third terminal got updated to Sambapos 5.1.61(Does not happen automatically. Somebody manually initiated the upgrade.) which migrated the database to the 125 version. The other two terminals were still 5.1.60 which used database version 124 but since database was upgraded to 125 those two terminals could not connect to it.


For next 5.1.61 update I added a “Search” button to find the default database backup folder.

It should be used on the SQL Server PC as local backup location should be accessible by SQL Server. If it is a network path it could be set manually from any terminal.


Thanks @Jesse you and Rick absolutely correct.

The interesting thing here was when the Update was applied 22/12/2016 the other 2 terminals (1 running the Server) were still running and HENCE nothing was affected. It was only when the terminals were shutdown due to a power failure we found the problem.

Not sure Emre if maybe a check could be done but in this case it would of not helped as I would of preferred not to upgrade to a Beta on a LIVE site :grimacing:

Thank you @emre

The problem we faced was the Server Machine had not been upgraded so we were locked out SambaPOS? So we could not do a backup.

How could we get around this as the User “Nt Service” was not an object available on our only terminal working and therefore we could only do a backup in Management Studio? Is it a matter of using Windows to create a User Account on the Machine not running SQL Server?

Your thoughts appreciated as we need a method to run a backup from a working Client that does not run the Server…

I dont know for sure but I would assume it should work ok because there is really not much difference… but potential that something would break could happen specifically if a version change was to change something on the database. I suspect that is why he allows the other terminals to still work… but if logged out and back in the check is in place… so he really already has a check and its initiated at login. Personally that sounds smart…

@pauln the problem is your database has been upgraded to the newer version. So if you were to install 5.1.61 it would work.

Yes, my only point, was I really wanted to backup before we upgraded the two Clients (1 with the Server). It just a protocol thing we have. Once we used Management Studio and upgraded Clients all was sweet.

Did you know you can enable an option in the backup settings that runs a backup automatically on EVERY version upgrade before it migrates?

Yes that may of helped but since the 22/12/2016 there had been lots of transactions after that backup - so we needed another… I think if all terminals were logged out then we would of not been in this position. Not sure how @emre could do a check on this before the upgrade…

1 Like

The main issue was someone running an upgrade to a beta version. It being Beta really is not relevant. The problem is someone upgrading it without your knowledge. I am not sure if Emre could build a check that would prevent that. Someone knowingly manually upgraded it. There are lots of prompts asking if your sure when you run the installer.

That same problem would happen regardless if it was beta or not. If a new non beta release came out and you did not want it installed yet someone could knowingly do the same thing and the same issue might happen.

He could probably implement something but would it really be useful? Then again you could just map a network drive and run a backup from any terminal.

What I am not clear on (even though Emre addressed it above ) is can you do backups from Clients (non DB Servers). As we tried mapped drives but as the Client did not host the DB they all failed? Ran Client as “Admin”, gave Eveybody Write access…

Hmm I could be wrong then… let me reread what Emre said. I personally do not run backups on anything other than server. Perhaps what we need is the ability to designate terminals as not able to migrate database, only server terminal can. @emre does that make sense?

I mean it would allow software update but it would not migrate database… so the terminal would be the only one not able to load. But if Server was updated it would migrate database and run the auto backup etc.

Then again I think basic user permissions of not allowing people to install or uninstall SambaPOS would kind of make the entire issue moot.