April 2011 - Posts

The Devs, The Bad and The Ugly – you choose!

How many times have you heard a DBA describing the teams they work with I wonder?

Well here’s my proof.

 

Posted by GrumpyOldDBA with no comments
Filed under:

Not thinking it through - the sequel ( Part 1 )

A few years ago I did a series of posts entitled "Not thinking it through" which were really cause and effect situations where an attempt to resolve a problem only caused another problem.

If you like to consider the route between business and application/database each request/requirement has the ability to become corrupted by each person or group of persons that come in contact with it. It's not exactly a new topic and it's not a criticism of any client past or present but an observation of process. I've seen so often managers who make decisions about what an application needs for its users, without actually asking the users of course, so what happens is that IT delivers what the users do not actually want, the users then often find a way around an application to get what they want, but usually what the application wasn't written to do.

My issue here,  leading wildcard searches and minimal searches. Leading wildcard searches do not scale, that's a fact, the end result is a table or index scan which can be really bad news if your table contains a few hundred million rows. I'd raised an issue concerning a search, where the user had entered a single s.  My point was that would I perform a google search for Virgin Airlines by entering a single v as my search criteria? My somewhat "grumpy" description was picked up and passed back up the tree so to speak from the developement team, I'd basically said that searching for anything by a single letter was absurd ( said I was grumpy! ) . Sadly the suggested solution was to allow a single letter search as long as one other criteria was also searched for, say another single letter! 

I also have the minor issue of a "contains" a single letter search. I'm struggling to understand how you wouldn't know more than a single letter, I mean it's not as if when you go the railway ticket office to buy a ticket from London to Bracknell you ask for a "Return to B, please" is it??  Please feel free to contradict me.

For reasons I can't go into full text is not an option, yet, but even if I build full test indexes is the ability to search for s going to be practical?  I'm not being disrespectful to any of those in the business and analysis process but it is a concern when no-one other than the DBA it seems understands the consequences of a decision. So not thinking it through -  don't allow users to search on a single letter - is it ok if they search on two fields like that ?

Posted by GrumpyOldDBA with 1 comment(s)
Filed under:

Windows doesn't like Squirrels ?

Strange goings on when setting a sevrice account password ^^  I was setting a service account for a dev  SQL server and wished to change the account password from that which it had been created with.

I can list all of this as I'm not giving away server names or passwords I use < grin >  So I opened up AD tools and set the password to  DEV08Thesquirrel  only to have it rejected as not meeting the complexity requirements.  Now I sort of remembered having some problems with passwords which were too long but couldn't remember if it was at work but decided to shorten the password to 14 characters , so DEV08Thesquirr  this was accepted without an issue. I pinged off an email asking if we had such a policy on password length, you might think this is an odd question but I had some considerable issues with my tesco.net email accounts where I keep forgetting you can only have, I think, a password of 8 characters, the problem is that it will happily accept a longer password but truncates it, very tricky!!

Anyway I had an answer that we actually accept passwords up to 127 in length. Must have some conditions around numbers and capitilisation and such - which my password complied with. I tried OneFlew2008cabbage and  OneFlew2008Thesquirrel    so perhaps squirrels weren't a problem, back to  DEV08Thesquirrel   nope still rejected, DEV08Thesquirrel#  nope   DEV08Thesquirre   nope   DEV08Thesquirr  yup.  Then I saw that we shouldn't use any more than 2 consecutive letters from tha account name - aha!  the account name started DEV08_  so that was that then, but hang on what about DEV08Thesquirr  ...  I tried DEV07Thesquirrel  and yes that was accepted.

Now many years ago I wrote a whole front end to handle passwords, just like this, and I too tried to stop users making use of their login name in passwords, but it was a daft idea trying to take small numbers of letters, any Andrew can't have  and   ,I'm colinleversuch work out the variations of words/passwords you can't use there!

So obviously it was asilly idea for me to start the password with the same start as the service account name, but it's a dev server and the domain account has no rights globally - so there you have it, a complete conundrum, squirrels notwithstanding.