Urgent ... Weird behaviour when incrementing system variable

The yesterday night behaviour.

In yellow (down) : the first ticket settled by Grecia (waitress 2)
In Yellow (up) : The last ticket settled by Celia (waitress 1)

When both working, the doubles

Definitevely no race condition.

… double post AGAIN …

race conditions … LOL :wink:

Yes, and that is exactly what I am implying.

Maybe, but that could manifest itself as a race condition.

I will not deny that Update Type:Increase appears to be broken when you update a value then subsequently read it.

But even that ^ could be a race. It doesn’t mean the value wasn’t updated, it just means the subsequent READ was too fast.

Or are you claiming otherwise? Are you saying that Increase is broken? How do you know for sure?

I think I did yesterday on Server (not RDP) so, i don’t think multi session too. It just pure Update Type Increase

  1. Trigger Update Program Setting with Increase (let say 20 now)
  2. Open SSMS to change the value back to 10
  3. Trigger Update Program Setting with Increase again it should be 21 now.

I think the value we pass to the
Update Program Setting
action is not read from DB.

No matter if Increase or Update type.

While I think that what you mean is:

Update Setting

  • It is read from the db (no need to check if DB/table/record is locked)
  • incremented
  • update into the db (db/table/record locked)

here impossible to have a race condition


  • It is read from DB (no need to check if locked)

maybe race condition, the value is maybe not updated yet, which - if the actions are executed in order - would make Ms SQL server useless.

I know for a fact I use this method with 3 terminals all windows tablets running sambapos and connected to database via connection string all Wi-Fi connected. Never once had it done this. I still think it’s unique to the terminal setup your using. I’m not saying it’s not a bug it certainly may be.

The event I use though is ticket created

It wouldn’t hardly ever be read from the DB. Increase we pass “1”, Update we pass “whatever” - it could be a value read from the DB or it could be the word “blah”.

For Increase we pass:

  • The Setting Name
  • The Setting Value (1)
  • The Setting Type

The Setting Name is the Name in the ProgramSettingValues Table.
So if using Setting Type Increase in this blackbox

Of course we have to expect that it will take the current value of the name and it will take it from ProgramSettingValues table; add Setting value (1) and Update that table.[quote=“QMcKay, post:157, topic:15062”]
Update we pass “whatever”

That whatever must be read from DB.

I get what you’re saying now.

Are you implying it is not reading the Value from the DB for the associated Setting NAME? Or that it is not updating it (when using Increase Update Type).

That might be the case but I don’t thing so, I think the value we use to tag; to update; (not to increase) is not read from db, it is an independant variable for each SambaPOS instances.

That value is related to {SETTING:SerialNumber}

I might be wrong but that is what I feel.

OK here is the test:

1 Instance, 1 User (No RDP)

Rule (Using Generic Action Type)

Test 1 (For the first time, no value has been read/load)

Manually write data to database

Click Test

I click Test Few More

Test 2 (Change Value in Database)

Manually write data to database (Reset To 0 and 100)

Click Test

See the result:

Increase: 4 (WRONG)

Update: 101 (CORRECT)

1 Like

Before I was using Increase but I was told to use Update instead.

Increase is different:
The function is supposed to read itself the db, while in Update we give that function the value we think we read from DB.
I also had problem (not exactely the same, I had soemtimes 3 times the same number) but that problem was maybe related to TAG and not Update Program Setting with Increase.

Good test. Looks like Update Type:Increase is broken. Looks like it is cached, and not read from DB.

What syntax are you using? {:X}, or {SETTING:X}, or {GLOBAL SETTING:X} ?

Nice test.

However I have it wrong with Update also using {GLOBAL SETTING:UpdateType}

Could you try?


can you try with GLOBAL?

{GLOBAL SETTING:XXX} Read from cache :scream:

Unbelievable we got another bug `{GLOBAL SETTING:X}’ = {:X}. So, change it back to {SETTING:X} You should be fine now.

EDIT: GLOBAL read from cache in “Before” but read from database in “After”. It seem it doesn’t know the value was update (I manually change database) so, it use local value but after Update Program Setting Action it read from database. @QMcKay

1 Like

actually I have it setup now with Update and I give the {REPORT SQL} value.

I haven’t had double today, I think I will stick with it until the patch.

Thanks a lot sukasem, QMcKay, JTRTech, kendash, and the ones I forgot!

1 Like

168 posts later and we uncovered 2 bugs. LOL.

Good work Team! :wink:

1 Like

was this fixed as im getting same issue.
What shall i change it to?