Attached is my time clock window. I have had 2 different people be able to punch in twice with no punch out. It should not allow them to do this. The button should not be enabled if they are allready punched in.
ClockWindow.vwin (19.7 KB)
I think the problem is they can press the button twice really fast before the query on the enabled button goes through. So try disabling the button in the first line of the script:event.source.enabled = 0Let me know.
These events where hours apart. I thought the same thing till I looked at the times.
Had a couple today had to fix. Here is a screen shot’s of the records queried out in the table. When it gets to this point ( 2 records in table ) it will not let them punch in or out. I have not seen it yet where there where 3 records.
The “Enable” on the buttons was looking at a view in the database. I just changed that to look at the table itself. We will see if that helps. Is a view not re-queried every time it is needed?
Travis,
Little confused here as both buttons are disabled until the sql query showed good one way or the other. Then the correct button would be enabled.
Just a thought, but I would also add a print statement in the button event script that contains any relevant information, including a time stamp. As long as Java logging is turned on, you can look at the logs afterwards. That might help.
Travis we are going to have to look into this more. I am heading home from vacation but was told it is doing it still.
While on vacation they 1 user managed to get punched in 3 times with no punch outs. I copied the data to the test server before I fixed it in the live environment. Attached is a screen shot, times are not even close. I am puzzled 
How does or will the Store and Forward come into play on this?
I am currently at 3.7 queries per second, which should not be anything. CPU load is 2-3%.
We had the problem again late last week. I had to remove the duplicates over the weekend.
Over the weekend I brought Ignition up to the latest version. I also brought both the Ignition server and the database server Ubuntu software fully up to date. I forced everyone out of the systems and rebooted both servers.
Complete project is attached not sure if you would need just window. I did not make any changes to this at all. I talked with Dave in tech support last week, we made some changes to the polling which did not work. He to looked at the code and felt this should not be able to happen. I can provide more info if needed.
BDI_Time_Clock (2011-04-25).proj (65 KB)
We are pretty puzzled right now as well. Dave and I have both looked into this issue. With the Enabled property of the Clock In button polling the only way to get duplicate records in the database is by clicking on the button in two different clients within 5 seconds of each other. You shouldn’t get two records so far apart.
Besides that, it is possible that you have staging and publishing set to manual and the clients out there are not at the current project. Maybe you need to publish your changes?
Do you have any database clustering setup?
You can add a print statement or a database logging statement in the clocked in button script that shows you the values of all dynamic properties in the window including the count(*) queries value.
You can also run the count(*) query in the button’s actionPerformed event and check that it is = 0. If not you can display a message and inform the operators to let you know when they get the message. If you don’t get the message it means they were able to clock in somewhere else (other than that specific button).
It seems we need to do some further investigation.
I will answer a couple of the questions here.
Staging and Publish is set at auto, so that is out. We are not doing and clustering on the databases so that is out.
Here it is again today.
I know, we are shooting in the dark a little. Like I said, the only thing we can do here is add some extra code to the clock in button to see whether or not someone is able to press it when clocked in.
The second and third entry look like they are due to a double click on the button, however I don’t know why they were even allowed to clock in because the button should be disabled.
To prevent the double click problem you can disable the button at the beginning of of the button event script. As for why they are able to clock in several hours apart without clocking out is still a mystery.
You should add a double check on the actionPerformed event of the clock in button that checks again to see if the person is clocked in already without a clock out time and if they are then just exit the event script without doing anything and popup a message box or log something in a file somewhere that says that someone was able to push the button when they shouldn’t have been allowed to.
That’s probably the next best place to start. If that popup box never appears then that would mean that there is another query somewhere that is inserting a record into that table, either within ignition or from somewhere else that has access to the database. This is quite strange indeed.
Mike, Dave and Travis,
We did get one to show up over night in the table. The first shows they must have went through process again and it worked, just a few seconds difference.
Mike,
Here is an upload of the project after the changes we made yesterday. Looks like we are going to need some input from developers here.
BDI_Time_Clock (2011-04-27).proj (72.5 KB)
Add this in as the first line of the clock in button event script:
event.source.enabled = 0That will ensure that we won’t be getting any entries due to the employee pressing the clock-in button twice quickly because we will be manually disabling it at the get go. Then we will be able to see if we are still getting those rare multiple clock ins that are hours apart.
Dave,
Here is the sql code for the tables.
[code]CREATE TABLE tbl_timeclock (
id_timeclock int(11) NOT NULL AUTO_INCREMENT,
id_employee int(11) NOT NULL,
clockin datetime DEFAULT NULL,
clockout datetime DEFAULT NULL,
PRIMARY KEY (id_timeclock),
KEY fk_employees_timclock (id_employee) USING BTREE,
CONSTRAINT fk_employees_timclock FOREIGN KEY (id_employee) REFERENCES tbl_employees (id_employee) ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=32383 DEFAULT CHARSET=latin1 ROW_FORMAT=COMPACT;
CREATE TABLE tbl_employees (
id_employee int(11) NOT NULL AUTO_INCREMENT,
id_company int(11) NOT NULL,
clocknumber int(11) DEFAULT NULL,
pinnumber int(4) unsigned zerofill DEFAULT NULL,
fname varchar(15) DEFAULT NULL,
lname varchar(15) DEFAULT NULL,
active tinyint(4) DEFAULT ‘1’,
PRIMARY KEY (id_employee),
UNIQUE KEY NoDups (clocknumber,pinnumber) USING BTREE,
KEY fk_companys_employees (id_company),
CONSTRAINT fk_companys_employees FOREIGN KEY (id_company) REFERENCES tbl_companys (id_company) ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=503 DEFAULT CHARSET=latin1 ROW_FORMAT=COMPACT;[/code]
So like we talked about on the phone, just add the button’s enabled property value to the insert query. You can get that value and assign it to a variable like so:
enabledVal = event.source.enabled Then you just insert enabledVal along with the rest of your items in the insert query. If we see a 1 (or ‘true’ maybe) being written then that means that the button is somehow enabled but the query that is setting the enabled property is returning false.
The good news though is that with that extra check inside the script you are no longer actually getting multiple clock in’s with no associated clock out’s written to the database.
Dave,
I did not get it put in yesterday. It is in now. We had a few more records added to table last night and from different IP addresses so not machine specific.
Good news is we were not using it to control a machine and broke something.