Strange Problem

[bjd4jc]

I have a time clock program that employees punch in/out with that I wrote in VB. It has been working flawlessly for about 6 or 7 weeks.

Some background:
When a user clocks in or out, the entry is stored in an Access XP database.

Yesterday, there were two employees who clocked in (on the same clock station - there are 6 total) and the program just kept clocking them in. They had like 25 clock ins that were 5 seconds apart each. I was looking in the database and they were still being entered so I rebooted the computer and it stopped. It only happened on this one computer. Other employees clocked in on the other 5 computers just fine. All 6 computers run the same exe (from a network drive).

There are no loops at all in the program. There are a few timers that just time screens out and such and there is a timer that checks the status of the database connection to make sure it is still up.

The network techs have been doing some upgrades. They replaced a switch over the weekend and are still tweaking it. Could there be something there?

Any ideas would be welcome because I am truly stumped.

Thanks

Brian

 

[DarrenWard]

Difficult to say without seeing your code.

How are you registering the clocking event?
Are you using a barcode scanner, or does the user just enter a code into keyboard?

Dazz (Like Harry Potter's schooling, I can't do anything without a spell checker)

 

[CajunCenturion]

In all likelihood,

Since the program was working fine for 6 to 7 weeks,
and
All 6 computers are running the same executable
And
after network upgrades were performed, 5 of the 6 are still working

Then,
most likely, something done in the network upgrade - related specifically to the machine which is failing, is the most likely culprit.


Good Luck
------------
Select * from Users where Clue > 0
0 rows returned

 

[bjd4jc]

Darren-

We are using touch screens that the employee uses to enter their employee number. They do not have access to the keyboard or the mouse - they are locked up in a cabinet. We are eventually going to move some sort of scanner.

Cajun-

I am kind of agreeing that it must be network related. But, I don't just want to use that as an excuse without being able to pinpoint it. Do you have any ideas on what could have happened with the network that you could just throw out so I can look into something. Is there a possibililty that the network somehow executed the same thing multiple times? How would this happen?

Thanks for replies. Any ideas are welcome!

Brian

 

[CajunCenturion]

I'm not by any means a network person, but just as a thought, perhaps a packet (clock_in) is being sent by machine number 6, properly received and executed.

Maybe, machine 6 is waiting on a confirmation, but never receives one, so it resends the packet after some time interval. Its just a shot in the dark, but maybe there is a confirmation message not being received ????????? Good Luck
------------
Select * from Users where Clue > 0
0 rows returned

 

[DarrenWard]

Possible, but have never seen anything like it before.
A repeating packet? maybe, but I would guess that this is more than just a packet, the client machine would be recording the time, the station number and the individual that is clocking in, that's a lot of packets that are bing resent time and time again. If it were happening I would expect it to be happening more than five seconds apart.

You say it happened to two people, I am assuming on two seperate occasions. Could it be that the touch screen is misfiring for some reason. Could a person touch a button and clock in, clock in, clock in, clock in, clock in ... or does it require a combination of event to complete the transaction.

Dazz (Like Harry Potter's schooling, I can't do anything without a spell checker)

 

[bjd4jc]

Darren-

The way the program flows:

The user selects clock in or clock out using touch screen.

The user enters their employee number using touch screen.

The user confirms they want to clock in/out by choosing yes or no on the touch screen.

The user is returned to the main screen where they can choose clock in or clock out.

The program logic does not allow the user to clock in multiple times with out clocking out unless a certain number of hours has elapsed (13 I think). I know the user tried to clock in again at least one time but got the standard error that they were already clocked in. It would take the user more than 5 seconds to complete a transaction even if it allowed them to do so.

The best explanation so far is that the packet is resending. I would like to confirm this a little more before I make it conclusive. Does anyone know more about this or where I can post to find more about this?

 

[DarrenWard]

Depends what network you are running, on a NetWare network you can see the amounts of packets and requests that are being received from a particular client at the file server, or remotely using RConsole or the Novell SDK stuff, and i'm sure that there are IP packet watching stuff that you could use under Windows, but this will not tell you why they are being sent, original request or re-send.

But this stuff will only help if you are watching the packets when/if the problems arises again. It is going to be almost impossible to tell why the multiple transactions happened after the fact. A new switch should not cause this sort of problem, and I can't understand why they would be tweekiing it, but that another matter.

All I could suggest is that you create a seperate database and log the software events that are fired as people clock in/out, and if the problem occures again you will be able to check the log to see if the software was firing or it was a communication error between the client and the server.

Failing that, if it aint happened again put it down to one of those things that happen now and again and stop worrying about it.

Dazz (Like Harry Potter's schooling, I can't do anything without a spell checker)