Type your data right (please)

Look, just use the right data type for a field please!

Really, it's not that hard to do:

• do you want to do some maths with it? Make it number or currency then
  
• is it numbers you'll never want to add up? Make it text already
  
• dates or times? Hmm, Date/Time then? But change the Format to make it appropriate OK? (like, I don't need the time if I'm just recording a date do I?)
  
• is it only going to be answered Yes/No? Hmm, what about a Yes/No field type (it's called a Boolean variable if you want to get geeky)
  
• and, please, if it's going to be an ID number than use the Autonumber type. It makes so much sense

There you go - easy peasy. Lemon. Squeezy.

So think about it, OK?

Oh, there's a Default Value option?

Yes, there's a default value option in the field properties bit of database table design.

So use it already!

There's all sorts of reasons and situation when you might use this feature. For starters, you might have a common value that many times will need to go into the box. Here's an example - let's say it's a stock control system being designed by someone who is completely hypothetically called "Steph"...

The field here is one where the user can say whether or not a bill has been paid.

The chances are that when the stock is booked in the bill won't have been paid - a bill is sent afterwards (the designer knows this because she spoke the the client - she knows the client's needs...). So a No is by far the most common value to go into the field when the record is created.

So, we use a default value of No!

You can also see some simple validation and whathaveyou. Of course, an alternative might have been to have used a Yes/No Data Type rather than a Text field...

Now, the same database also needs to enter the Date In of the stock being stored. Here again we can use a default value - the chances are that most of the time the value will be the current date.

Again, the designer knows this because she spoke to the client about it and found out. For sure. Can I stress that this step is really, really important in all of this? Thanks.

Here's the field properties:

We can use Date() to get the current date in that cell.

Note the validation here.

It's possible, although unlikely, that a different date might need to be entered. A container might be fortgotten about or not entered for some reason. Because of that the validation rule has been set to accept any date from 7 days before today until tomorrow - a container might sometimes be logged on the system the day before it's actually present on site.

Do I need to tell you how she knows this?

Here's the Planned Date Out field properties:

The minimum length of time a container can be in store for is 1 week apparantly. Seems a bit odd, but that's the way it works. So the Default Value can be set to a weeks time - Date()+7. The Valudation rule here might need to be >Date()+6 actually - I think you'd need to test all of this.

---

Now, testing...

All these rules and default values need testing. This goes in the Testing section of a report - in the Test Plan. In all this you clearly have to test the Boundary Values as well as values which are obviously going to the right and those that are obviously going to be wrong.

So, if I'm testing this all today (10/3/09) then I'd be checking if I could enter 2/1/06 (hopefully no - it's clearly wrong), 9/3/09 (OK), 2/3/09 (shouldn't accept it - and it's a boundary value) and 3/3/09 (should accept it - it's a boundary value again).

This demonstrates the importance of a clear test plan at this sort of level - it shows you the detail of testing that systems like this need.

Data Overload - need Protection...

Who's got your data on their computer?

Do you know? Probably more people than you might imagine - school, doctors, hospitals, supermarkets, the tax people, the police (perhaps...), anyone you ever registered with online or filled out a paper form for. The list could be, and probably is, endless.

But do you know what they do with your data? Or, rather, what they're allowed to do with your data?

There are rules - the good old Data Protection Act of course.

But does every company or organisation play within the rules?

Seems not.

---

Building Data Regulations:

Consulting Association, a company based in Droitwich (that's near Birmingham, sort of) certainly don't seem to have done so.

They hold data on people who work in the building industry. Big companies - Balfour Beatty for example - would go to them to find out about people they might employ. I suppose that might be quite useful: a company who can tell you what qualifications your future employee might have or what their experience is for example.

But, you see, amongst other things the firm would warn employers about possible "trouble makers".

You know, union organisers.

Following a raid ... investigators discovered that the Consulting Association's database contained the details of some 3,213 workers, the ICO said.

Employers paid £3,000 as an annual fee, and £2.20 for individual details, the ICO said. Invoices to construction firms for up to £7,500 were also seized during the raid.

From Firms in data row deny wrongdoing - BBC News report 6/3/09

Now, I didn't know being in a union or being an organiser was an offence. I thought it was just common sense - I've been a union organiser in my time. It means I might be prepared to stick up for myself in an argument with an employer. I might know about the rules and regulations surrounding things like over time or health and safety.

This is common sense - but it seems that, surprise surprise, the big firms don't like dealing with "union organisers". People who know their rights.

Or, it seems, people who might raise concerns about health and safety matters. You know, on building sites. Like, that isn't important or anything is it? Or about asbestos. The stuff that can kill you if you breath enough of it in: not straight away (like falling from scaffolding that's not been properly put up...) but in years after horrible pain.

You know, you wouldn't want to actually employ someone who'd made a fuss about any of that sort of stuff. Would you?

That stinks. Workers have a right and, to me, a duty to protect themselves. No wonder the Information Commissioner says that the public need to assert their data right.

---

Data Protection to the rescue:
Fortunately this has all come out into the open. And, even more fortunately, it seems that Consulting Association has fallen foul of the good old Data Protection Act this time.

You see, they didn't register with the Information Commissioner. They didn't stick to the rules. The company that noted that one of the people on its database was a problem because he was "Irish ex-Army, bad egg" didn't cover one of the most basic steps that anyone holding data about anyone else needs to do.

Shame.

A few Project Management links

Oooh, a Project.

I love a good project. It's just the management bit that's a pain...

Some things that might be slightly useful - all from Wikipedia:

• list of Project Management topics, including activities which typically occur during a project
• the Systems Development Lifecycle, which is bascially the theory behind what happens during a project of any kind, an IT project specifically
• a Glossary of Project Management
• what RBS means

The wiki page on Project Management has a series of Project Management Stages on it. These are probably a good base to use to break down a project.

1. intiation - which "determines the nature and scope of the development"


2. planning or development - which designs and perhaps creates a prototype which is tested


3. production or execution - which produces the actual thingy


4. monitoring and controlling - which includes checking that everything's going well. The wiki page on this is well worth a look for ideas. It can also include maintenance - making sure that whatevers produced continues to work


5. closing - finishing off and handing it over. In the real world this is quite often the "getting paid" section!

It's well worth taking a look at the wiki section on that for ideas. Promise.

Adding stuff to a database field

So, you have a database table.

There's a field that you want to add something like Amps to. So it's going to be, like 13 Amps or 5 Amps or whathaveyou. Always Amps.

Easy to do.

The field type'll need to be text for this.

Then you simply set up the Input Mask in this sort of way:

This should work for text fields as well - you simply need to make sure the input mask characters work properly the way you want them to.

The section in the textbook on Input Masks is p.28-29 - assuming you haven't spilt orange juice over your textbook so you can still read the pages.

You can do the same thing for an Autonumber field as well - say that you need to add a standard set of text before a stock code for example. In this case the Input Mask simply needs to be something like "STA"000 and the field type Autonumber.

All of this adds usability to your database. It makes it easier for the user to use it. This is a Good Thing.

Careful what you type!

Hmm, so my meetings are boring?

Good job I didn't put that up on Facebook or somewhere then; I could get sacked, rather like this Essex teenager did:

A 16-year-old girl from Essex was fired after she described her office job as "boring" on her Facebook page.

Kimberley Swann, 16, of Clacton, had been working at Ivell Marketing & Logistics, in Clacton, for three weeks before being fired on Monday.

"I think they've stooped quite low," she said.

Facebook remark teenager is fired, on the BBC Essex site

"Stooped quite low"?

Of course, if she hadn't added half her workmates as friends then I don't suppose they'd have seen the comment. Some people might say this raises issues about privacy and the internet. Yes, it might - but it also raises issues about how careful you have to be about putting stuff up on the internet that you don't want other people to see.

It's all very easy to quickly blog something, or stick it on a Facebook profile or Tweet it or whathaveyou, but once it's there it can be tricky to get rid of, particularly if you put it anywhere near the public domain.

So, hard done by for getting sacked? Or a little bit naive about what the internet and the ubiquitous computing it brings with it means?

I'll go for the second of those please Bob.

Oh, I should just say how much I adore the meetings I go to for my proper job by the way...

Meetings...

Stuck in meetings all day.

Ugh: this is one good reason not to grow up and get a proper job!

Meetings all day yesterday (yes, that was a Sunday...) and all day today. My brain will try and rebel I'm sure...