The following Dodgers have been smited by the JDK for their crimes against Jam:
All the girls! for picking on the JDK and damaging his already delicate self esteem!
The Basserd Who Nicked Copper's Stuff For the offense of nicking Copper's stuff. You are a tw*t, whoever you are and we all hope you get run over by a tram in Nottingham. Or Liverpool. Or whereever else they have trams!
Copper For the crime of playing with her Wii instead of her Jammie pals!
Sorry. I have a boring work related question here. I've been asked to look into building a secure access database for recording staff holidays on and, as I'm a lazy bugger was wondering if anyone else had already built one that I could steal and pretend was my own, or perhaps point me to an example that I can get some ideas from.
Nope - dunno - but weren't you gonna come back to me on how can I make an error message appear if the date entered is <= todays date in a field? hmmm? hmmmm?
__________________
I'll take arrogance and the inevitable hubris over self-doubt and lack of confidence.
"Everyone has a plan, until they get punched in the face" - Mike Tyson
What are you having the most problem with, the fact that it must record staff holidays or the security part? or both seeing as how you are a lazy bugger and all?
For security, I can use the logon Id and workstation id stuff from the other day - I just need to find a way to disable access to the backend with the shift key, which shouldn't be too hard. none of my users know anything about Access, anyway.
Not quite sure how to start at the moment - I have the usual high standard of requirements - i.e. 'we need a database to record staff holidays on... can you do it in that access thingie?' I'm sure they'll come up with all sorts of useful comments after the event!
What I'm pretty sure I want, though is some sort of authorisation procedure, so that the line manager much confirm the holiday once it's been input. And it needs to keep a record of any changes made. And it has to be really easy to use - and most importantly, it should not require ANY paper at all, no matter how obsessed with bits of paper the bosses are.
R. Hicks has a shift key bypass demo that is pretty handy in the code archives here as for the keeping track of changes, search for audit trails and such
Audits are kinda of a pain in the butt with access because you have to code everything yourself. The simplest thing to do is just record when a record changes, not neccessarily how it changes. The how part gets complex and adds to the size of the database imensely. If you were using SQL Server or Oracle, these DBMS's capture the "how" part for you and you can do stuff with it then using triggers.
quote: Originally posted by: ddvmor "And it has to be really easy to use - and most importantly, it should not require ANY paper at all, no matter how obsessed with bits of paper the bosses are."
So, let's say you do build this DB, and I for one am all for it, will this mean that fcukers at work will no longer be able to fubar Suey-mate's Excel application?
I'm tired of people trying to do $h*t like this in Excel!