Page 1 of 1

Background tasks

Posted: Tuesday 8th June 2021 2:16am
by AndyGable
Hi everyone,

I have a question I would like to ask.

As most of you know I'm porting my EPoS software from windows to Linux by using Gambas.

I have a database update function in my windows version that runs In the background on the POS terminal once the cash drawer opens (the function display a small "updating" icon on the user screen and the. Update stock levels and tenders etc on the central database once it has consisted the update icon is hidden)

Is there a way I can replicate this in Gambas as I have had customers who have had sale that have had over 100 items (and if they are updating everyone in loop it will lock the till for a few seconds)

Ideally this option should be able to handle multipule updates (say one sale is for 100 items and then Another sale is for 2 items and then A sale for 5 items) in a perfect world the 100 items would run and once that has been processed the software would then process the 2 items and then the 5 items (like a first come first serve option) but I want to keep the till it self operational.

Is this possible or should the updates be saved to a file and have another gambas program (headless) do the database update?

Re: Background tasks

Posted: Tuesday 8th June 2021 8:06am
by Quincunxian
Hi Andy,
What back end database are you using ?
What is the database sitting on ie: hardware ?

One thing in your post caused me some concern. If you are updating stock levels, then you are going to need to do this near real time, otherwise your other users may order stock that you don't have. Could be misreading your methodology though.
So from that, the optimum solution would be to do transactions in as close to real time as possible.
Unless you have 00's of users then I'm struggling to understand why the transaction would take a 'few seconds'
Assuming there is other factors involved. network speed etc

Re: Background tasks

Posted: Tuesday 8th June 2021 9:11am
by cogier
A possible solution would be to save each completed transaction to a folder saved with the 'Till' it came from and the date and time in the file name. A background task (perhaps a different Gambas program) would take each file in the correct order, process it and rename it to indicate it had been processed. This way you would also have a folder containing a history of all the transactions.

If you are looking for a program with a background task, have a look at the TaskExample or InFile on the Gambas Farm.

Re: Background tasks

Posted: Tuesday 8th June 2021 8:08pm
by AndyGable
Quincunxian wrote: Tuesday 8th June 2021 8:06am Hi Andy,
What back end database are you using ?
What is the database sitting on ie: hardware ?

One thing in your post caused me some concern. If you are updating stock levels, then you are going to need to do this near real time, otherwise your other users may order stock that you don't have. Could be misreading your methodology though.
So from that, the optimum solution would be to do transactions in as close to real time as possible.
Unless you have 00's of users then I'm struggling to understand why the transaction would take a 'few seconds'
Assuming there is other factors involved. network speed etc
Hi Quincunxian

Sorry for the delay in replying here are the answers you requested

The database back-end is a MySQL 5.8 Server
It is running on a HP Micro server running on Debian 10 using the TCP/IP communication

The stock level must not be updated until the end of the sale in case the cashier voids the sale all together. I have been using this background method on my Windows PoS for over 3 years and I have never had any issues with stock being sold out (normally the shop has not booked stock in correctly)

When we did the update before the next sale on the Windows PoS the system ran extremely slow with more then 10 items in the sale as it was updating the following

updating the stock level for item
updating sale history for item
updating cashier sale history
updating sale location value for item

and it looped through each item (as I have it stored in a List array on the Windows PoS and I was thinking about doing something simular on Linux)

Re: Background tasks

Posted: Tuesday 8th June 2021 8:14pm
by AndyGable
cogier wrote: Tuesday 8th June 2021 9:11am A possible solution would be to save each completed transaction to a folder saved with the 'Till' it came from and the date and time in the file name. A background task (perhaps a different Gambas program) would take each file in the correct order, process it and rename it to indicate it had been processed. This way you would also have a folder containing a history of all the transactions.

If you are looking for a program with a background task, have a look at the TaskExample or InFile on the Gambas Farm.
Hi Cogier,

I like your idea of off loading the database updating to another program in the background of the system and once it has been updated the file can be deleted as the database it self will keep a sale log of everything that is sold.

Could I use the acual transaction number as the file name?

example 0000001.dat and inside it have the following

[Products]
50201600,2

[tender]
cash|1.50
Change|0.20

[Journal Roll]
202100604,21:38,001,001926,1105,0000,CADBURY CRUNCHIE BAR 40G
202100604,21:38,001,001926,1105,0000, 2 @ £0.72 £1.44 A
202100604,21:38,001,001926,1105,0000,________________________________________________________
202100604,21:38,001,001926,1105,0000,TOTAL DUE £3.78
202100604,21:38,001,001926,1105,0000,5 Items Sold
202100604,21:38,001,001926,1105,0000,________________________________________________________
202100604,21:38,001,001926,1105,0000,CASH £1.50
202100604,21:38,001,001926,1105,0000,CHANGE DUE £0.00
202100604,21:38,001,001926,1105,0000,04 June 2021 21:38 001 001926 1105 0000

Re: Background tasks

Posted: Wednesday 9th June 2021 12:30pm
by 01McAc
I suppose I had a similar question for my project of the lens database: https://forum.gambas.one/viewtopic.php?f=13&t=1055
I created a new background task for a bulk update in the sqlite database:
hTask = New MyTaskFTS As "hTask"
MyTaskFTS.class looks like this:
Inherits Task

Public Function Main() As Variant
  
    Dim DBS As New Cls_SQL_DataBase
    Dim $Rec As Result
    Dim $Query, $QueryUpdate As String 
    Dim sToday As String = Format(Now(), AV.FormatDBDateNoTime)
    
  
    $QueryUpdate = "UPDATE App_variables SET Val='" & sToday & "' WHERE Var='LastCreateFTS'"
    $Query = "SELECT * FROM App_variables WHERE Var='LastCreateFTS'"
    $Rec = DBS.$Con.Exec($Query)
    If Not $Rec.Available Then 
      Return False
    Endif
  
    If sToday > $Rec!Val Then
      DBS.Refresh_FTS
      $Rec = DBS.$Con.Exec($QueryUpdate)
      'Wait  
    Endif
    Return True
End

Re: Background tasks

Posted: Wednesday 9th June 2021 2:10pm
by cogier
Could I use the actual transaction number as the file name?
There is no reason you can't save the file as you suggest. I would just be careful that if you have multiple 'Tills' you ensure the names don't end up the same.

Perhaps 1000001.dat for 'Till' one and 2000001.dat for 'Till' two.

Re: Background tasks

Posted: Thursday 10th June 2021 1:12pm
by AndyGable
cogier wrote: Wednesday 9th June 2021 2:10pm
Could I use the actual transaction number as the file name?
There is no reason you can't save the file as you suggest. I would just be careful that if you have multiple 'Tills' you ensure the names don't end up the same.

Perhaps 1000001.dat for 'Till' one and 2000001.dat for 'Till' two.
Hi Cogier,

I do not think i would need to worry about this as each till would store locally and have a database update program running in the background on each machine

With this method If the database app crashed for some reason at least the data would still be sat in the local directory (and I assume I could somehow start the database app again from with in my PoS Software (like on a Menu key)

The Idea was as follows

When the PoS Starts it would run (example) Startup.sh and this would then do the following

1. Check my ftp server for any updates to any of the programs and if they exist download them to their folders
2. Start the Database sync program (for sending data to the PoS) and if any data is in the folder it would sent this before moving onto the
next task.
3. Start the Printer Module (as I support multiple Printer types I was thinking this would be the best way to go)
4. Start the Journal Module (this would either be a Electronic module (stores into the database) or prints on the TM-U950 printer)
5. Start the Card Processing Module (if set to do so)
6. Start the Gift Card Module (if set to do so)
7. start the RS232 barcode scanner module (I am not sure how I would communicate this to the PoS I was thinking about using Pipe but is that quick enough?)
8. Start the RS232 Scale module (this may link into the Scanner module if they are combined units)

Once everything is loaded correctly and no issues has been detected then the start up script would then switch to x server and start the PoS application.

Re: Background tasks

Posted: Thursday 10th June 2021 1:23pm
by cogier
Wow! There is a lot going on there.

I am interested on how you do your printing with Gambas. I have managed to get it to work reliably using gb.cairo which I built in to a program for work that creates labels with text and barcodes. You are using RS232 barcode scanners, is that a challenge? I use USB barcode scanners which basically are seen as keyboards.

Re: Background tasks

Posted: Thursday 10th June 2021 1:30pm
by AndyGable
cogier wrote: Thursday 10th June 2021 1:23pm Wow! There is a lot going on there.

I am interested on how you do your printing with Gambas. I have managed to get it to work reliably using gb.cairo which I built in to a program for work that creates labels with text and barcodes. You are using RS232 barcode scanners, is that a challenge? I use USB barcode scanners which basically are seen as keyboards.
I have to use RS232 scanners as they are high volumes and That is what the customers all ready have installed The linux version of our software should be able to be used on older hardware that only has RS232 interfaces as most of my customers are coming from Either DOS or no PoS systems at all.

The printing is done direct to the printer via its control chars.

The Windows Version uses OPoS to communicate to the Printer (all I had to do was talk to the OPoS service) but in Linux there is no why I could use OPoS (as it is a Windows only thing)