Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TheBoy]

...to drive over to my bro's and slap some of his staff with Sammy. Spent most of last night and tonight sorting out a cocked-up refund in his database.

Upon quizzing them how they managed to make such a mess (I write the code  so have a natural interest in closing the hole they fell through), but they don't know what they did. Grrrrrr 

[cem_devecioglu]

did you log the transactions in seperate tables.. with columns like  time, user, action like insert update delete and other necessary fields..


but with this you can only reverse the action to a specific time point.. may be of some help to what they have done..


sql logs generally not helpful

[jimbobmccoy]

Can you reprint the receipt, or view the transaction as the till would display it, rather than from the database side-if so, can you then recreate it?

This is normally what I end up doing to figure out the marvellous ways retail staff manage to screw things up, as trying to look at it logically within a database makes little sense as it lacks context.

[chrisgixer]

Why would counter staff be expected to repeat a fault they didn't know was about to happen? If the fault occurred again, then they might look out for it, maybe.

That's a system testers job. Not the end users job.

Poor implementation. System fail. Don't blame the staff.

[jimbobmccoy]

It's not an expectation of them to repeat the fault, more for them to tell you what they actually did so you can figure out where the fault is.

From experience, 99% of till issues are down to user error, the till only does what they've told it to, so figuring out what they told it is the first step.

Looking at transactions in a database makes this hard-you may have one table to hold user info, one for stock info, one for tender type and so on, or even one column that holds the summary of the whole sale that gets broken out by specific queries. Piecing all this together is much easier if you can replay the transaction.

I would expect that in most retail environments refunds are signed off by at least a supervisor, and I'd at least expect them to be able to tell me what they put through the till. Sadly this isn't always the case, and seems to be what's added to TB's issue.

It may well be a system issue, but without knowing what the till was told that's hard to determine.
Testing also involves recreating the initial fault if possible.






All this makes the huge assumption it's not a systems fail due to poor implementation as suggested though

[cem_devecioglu]

Why would counter staff be expected to repeat a fault they didn't know was about to happen? If the fault occurred again, then they might look out for it, maybe.

That's a system testers job. Not the end users job.

Poor implementation. System fail. Don't blame the staff.

Chris, even on a small  application database you may have 10 to 50 tables (different entities in computer language)  in which there may be more than 30-40 to hundreds of different transactions that includes mutiple table updates, inserts , deletes.. As applications change as a function of time,  the initial design considerations are mostly altered but the application itself is bound with lots of old data/relational parent or child tables ..  Generally the problems occur after this new implementations are added as there will be minimal time for testing the unknown number of probabilities on a production database..

[TheBoy]

Poor implementation. System fail. Don't blame the staff.

Absolutely it appears to be a coding error, in that it allowed an operator to do something that caused problems. But some clue as to what was down might be helpful, so we I can fix the loophole.

[TheBoy]

I would expect that in most retail environments refunds are signed off by at least a supervisor, and I'd at least expect them to be able to tell me what they put through the till. Sadly this isn't always the case, and seems to be what's added to TB's issue.

That's the idea, but they all have been granted till supervisor permissions, with reporting metrics being used to identify any staff abusing it 

[chrisgixer]

Why would counter staff be expected to repeat a fault they didn't know was about to happen? If the fault occurred again, then they might look out for it, maybe.

That's a system testers job. Not the end users job.

Poor implementation. System fail. Don't blame the staff.

Chris, even on a small  application database you may have 10 to 50 tables (different entities in computer language)  in which there may be more than 30-40 to hundreds of different transactions that includes mutiple table updates, inserts , deletes.. As applications change as a function of time,  the initial design considerations are mostly altered but the application itself is bound with lots of old data/relational parent or child tables ..  Generally the problems occur after this new implementations are added as there will be minimal time for testing the unknown number of probabilities on a production database..

I don't recall Bill Gates phoning me up asking what I did, every time his gay operating system crashed. Although clearly they installed logs via a back door later on. If he did, I'd tell him, I just looked at it and it had crashed. I don't know when it decided to crash, or what I did that might have caused it to crash. That's not my job, its yours!

(It does also continually insist on blocking me using the machine, whilst updating, though. How many bloody updates per day is acceptable? )

Anyway, it's not a pc so I'll shut up now.

[TheBoy]

(It does also continually insist on blocking me using the machine, whilst updating, though. How many bloody updates per day is acceptable? )

Your little netbook? A bit underpowered, so the updates (2nd Tues of the month) will hammer the poor thing a bit I'm afraid.

Anyway, it's not a pc so I'll shut up now.

/Panto mode
Oh yes it is

[chrisgixer]

(It does also continually insist on blocking me using the machine, whilst updating, though. How many bloody updates per day is acceptable? )

Your little netbook? A bit underpowered, so the updates (2nd Tues of the month) will hammer the poor thing a bit I'm afraid.

Anyway, it's not a pc so I'll shut up now.

/Panto mode
Oh yes it is

No not just the netbook. Maybe I dont use pc's enough.

I love my little netbook though.

[TheBoy]

(It does also continually insist on blocking me using the machine, whilst updating, though. How many bloody updates per day is acceptable? )

Your little netbook? A bit underpowered, so the updates (2nd Tues of the month) will hammer the poor thing a bit I'm afraid.

Anyway, it's not a pc so I'll shut up now.

/Panto mode
Oh yes it is

No not just the netbook. Maybe I dont use pc's enough.

I love my little netbook though.

MrsGixers PC should be more than man enough to install updates in the background 

[Rods2]

As hard as we try to make things foolproof, unfortunately, the fools are winning.

[cem_devecioglu]

Poor implementation. System fail. Don't blame the staff.

Absolutely it appears to be a coding error, in that it allowed an operator to do something that caused problems. But some clue as to what was down might be helpful, so we I can fix the loophole.

programmers dont make error , they use "different" logic


other kind of problems are unexpected data field entries (values) which effect the conditional branching and order of ops.

[Marks DTM Calib]

As hard as we try to make things foolproof, unfortunately, the fools are winning.

As I have said many times, the pace of development is only beaten by the human races ability to produce a better idiot