Urgent ... Weird behaviour when incrementing system variable

[QMcKay]

… double post AGAIN …

race conditions … LOL

[QMcKay]

@plume

Race condition inplies a read/write to database.

Yes, and that is exactly what I am implying.

@plume

Our problem is that somewhere there is no reading/write to DB where there should be.

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?

[sukasem]

@QMcKay

Are you saying that Increase is broken?

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.

[plume]

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

Tagged

• 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.

[Jesse]

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

[QMcKay]

@plume

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

No matter if Increase or Update type.

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”.

---

[plume]

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”
[/quote]

That whatever must be read from DB.

[QMcKay]

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).

[plume]

@QMcKay

Are you implying it is not reading the Value from the DB for the associated Setting NAME?

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.

[sukasem]

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)

[plume]

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.

[QMcKay]

@sukasem

See the result:

Increase: 4 (WRONG)

Update: 101 (CORRECT)

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} ?

[plume]

Nice test.

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

Could you try?

[sukasem]

@QMcKay

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

Using {SETTING:X}

[plume]

@QMcKay

{GLOBAL SETTING:X}

can you try with GLOBAL?

[sukasem]

{GLOBAL SETTING:XXX} Read from cache

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

[plume]

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!

[QMcKay]

168 posts later and we uncovered 2 bugs. LOL.

Good work Team!

[ub26]

was this fixed as im getting same issue.
Mine is set to {GLOBAL SETTING:ORDERNUMBER}
What shall i change it to?