I'm using VB.NET, and I'm currently using two Timer objects - one to monitor the external operation, and a second to perform the db writes.
I've been advised to look into using the BackgroundWorker object instead, and wanted to better understand exactly what this does, and how I'd benefit from using it. I'm hoping for some insight on how the BGW object works, and why it would be better than a Timer object.
Essentially my program interacts with an automated "picking" system. My program writes rows to an integration table. The pick system reads data from those integration tables, and then performs tasks. The pick system reports success by removingthen removes rows from those tables, or writes values into an Error table, and my program responds to those actions. The process boils down to this:
1. My program adds rows to a Detail and Header table (the "integration" tables)
2. "Pick system" reads those rows and performs tasks.
3. "Pick system" removes the rows from those tables upon a successful "pick", or writes records to an Error table upon failure
4. Timer1 in my program queries those tables periodically, and adds values to a Queue object for successful picks.
5. Timer2 reads the Queue objects, and writes values to another database based on the Queue object.
Step 4 is the first Timer. As mentioned above, it checks the integration tables. If there is a successful pick, I add items to a queue.
Step 5 is the second Timer. It reads the next Queue item and attempts to write records to a database. This operation can take some time, depending on the complexity of the data.
My question is - what's the benefit in using the BackGroundWorker instead of the Timer? The Timer object seems ... klunky ... whereas the BGW object seems better suited for what I'm doing - but I don't really understand the BGW and how it works.