Those Pesky Recruitment Consultants

Let me tell you about Vic* - he is a recruitment consultant, of course, in other words a salesman.  I used to be a salesman, so I know a bit about what goes on.  This all happened a couple of years ago, but I doubt if Vic has changed much.

Vic had a chat with me, got my CV, and put me forward for a job.  But he didn't actually get round to telling me that he was putting me forward, nor did he send me a job spec, nor did he tell me who the client was, which is a bit naughty.  But, you know - sometimes you have to be a bit proactive in this life, and enthusiasm counts for a lot.

Which was fine until Bob* called.  Bob had a chat, got my CV, told me about his client, sent me the job spec, gave me the client's name, and I agreed that Bob should put me forward. 

You see where I'm going, don't you?  The client wisely didn't want to get involved with a nest of vipers. 

Then Vic had another go, on a new job a few months later.  He told me about the client - Joseph Bloggs International*, got my CV, told me he was putting me forward.  Lessons learnt - well done Vic!

Two or three other agencies contacted me about Bloggs -I told them I had already been put forward, and they shrugged their shoulders and moved on.

Then - nothing.  No interview, no feedback.  Nothing.  I shrugged my shoulders and moved on. 

Until I met Susan* - she was interviewing me for another job.  Susan was the outgoing DBA, and she was leaving to go to a firm called Joseph Bloggs International.  Nice step up for her, really interesting job.  Yes indeed.  Except looking at her profile she actually wasn't so well qualified as me.  And although I'm sure she will be great at Bloggs, they really should have interviewed both of us before choosing her. 

Vic had done it again.  He got his hooks into me, but didn't land the contract with the client, so didn't actually put me forward.  Hence no feedback. 

So advice please - as a mere candidate, what am I supposed to do when an agency rings me?  If you work in recruitment please tell me the secret formula that renders consultants powerless to tell me big fibs.

*Names changed to protect the guilty

  

So farewell then Hartkaiserbahn.

The Hartkaiserbahn was the funicular railway that took skiers up from Ellmau to the Panoramic restaurant.  And on into the Skiwelt.  Here's a photo which I scrounged from John Barr, the Austria Ski Guide, of the funicular in the 1970s, when his mum and dad went there on their summer holiday. 

And here's one I took in March 2015.  It's just coming down into the bottom station to collect me.  And a few others, of course.

And they have spent the summer of 2015 removing it.  (The ski lift people I mean, not John's mum and dad.)

It's progress, of course.  They are replacing the old funicular, dating from 1970, with a state of the art gondola. 

Here's a photo from the Skiwelt site of the crane removing the carriage.  

It was a bit of a dinosaur.  Pretty much every time I used it, it was horribly cramped, standing room only, rather less than user friendly.   You had to climb up a set of steps to get to the top of the carriage, clumpitty clump, then fight your way in.  If you were anything less than 1.6m tall you would struggle to stay upright as you probably wouldn't be able to reach the hanging straps.  

A nightmare for the maintenance engineers, parts would have to be made specially to order if anything ever went wrong. 

The track went up the mountain.   The track came down the mountain.  And halfway up it split, the two carriages thundered past each other, and then back they went onto the single track again.  Scary stuff. 

The new one promises to be far more comfortable, quicker, double the capacity, heated seats, hot and cold running wifi, the best thing since sliced bread. 

And yet...

And yet, it's a sad day for the history of skiing. Excuse me while I wipe a little tear away. 





   

Ooops

I came across a job the other day - it was called Check Disk Space.

A laudable aim - we should all check disk space every now and then, maybe even constantly if we have one of these magical monitoring systems that do everything.  This was actually an old legacy system, dating back to the Palaeolithic era of SQL Server 2000.

But the job was failing.  It had worked for years, and now it didn't work.  So I thought I should look inside it.  Turns out it was running a stored procedure called usp_check_disk_space or something like that - so far, so consistent.

So I thought I would have a look at this elderly stored procedure, which has been running for years and giving nobody any trouble.  and it seems it was running xp_fixeddrives to get the amount of free space on the drives, then writing it to a table, and then - er - truncating the table.

Ooops. 



  


 

The Perfect Job

The agencies email, and ring me, and connect on Linked In.  It's nice to be wanted.  But I'm not actually looking for a new job, just keeping my options open.  I would be a mug to refuse to talk to them - they might just have the perfect job for me... 

And of course one day I might be looking, so I want to keep in with those agency bods.  So I tend to tell them that I'm looking for double my salary and a permanent SQL DBA job in a brewery.  Ha ha!

Until the day that the chap tells me that he is looking for a permanent SQL Server DBA in a Brewery!   Oh, well played sir!

I won't be able to apply - I have too many family commitments to consider relocating.  But if you are interested, track down Richard Iles at Computer Futures.  And mention my name - maybe he'll buy me a beer?

Modern Jobs - the Process Development Coordinator

Our company Intranet had a job post today.  I have not the faintest idea what a Process Development Coordinator does. 

So I read the Job Description

This is a varied role, working on a premium brand which is still in growth phase. The account is open 7 days per week between the hours of 0800 -2100 and you will be rostered rotationally across those hours, however the majority of your hours will be worked 9-5:30 Monday to Friday. This is a high profile role with lots of client contact and requires the personal qualities of self-motivation, learning orientation, analytical thinking, process orientation and patience.

Candidates must have a demonstrable understanding of training.

The main purpose of this role is:

 

·           Undertake ongoing root cause analysis to identify opportunities for process improvement

·           To work  with the clients to ensure consistency of process and approach across both sites

·           To provide recommendations around achieving a demonstrable improvement in challenging external quality measures

·           Manage the Training Associate team workflow

·           support operations to achieve high standards to enhance the customer experience and increase productivity

·           Share in the operational workflow and customer facing duties.

 

 

Required abilities

·         Committed to the delivery of an exceptional level of customer service

·         Excellent communication skills

·         Ability to pay close attention to detail

·         Natural ability to inspire, motivate and energise others

·         Shows respect to others in a positive manner and builds strong working relationships

·         Strong team player and role model

·         Enthusiastic, positive, resourceful and resilient

·         PC literate

I'm still none the wiser.  Am I getting old?

The Missing Sundays Mystery

One of our key customers sends us a datafile every day, and it automatically gets loaded.  Except sometimes - it doesn't...

<Cue theme from "The Twilight Zone">

So I wrote some code to see when data was being loaded.  Sure enough, it works every day of the week, but on the Sunday between Christmas and New Year - it failed to load.  The following Sunday - it worked fine!  But since then, it failed every Sunday.  Only on Sunday.  Then on Monday, a double dose of data gets loaded. 

Now - I didn't tinker with the database - it's an Oracle system, running under a Cron job  under Unix.  So a long way over to the Dark Side.  I don't even have access to the box it runs on - even if I wasn't afraid to touch it, I couldn't tinker. 

And the developers swear blind that they haven't mucked about with the application for months...

I looked in the FTP site - there was a litter of .tmp files, apparently some sort of by-product of the loading, renaming and moving process.  No clues there though, and removing them made no difference. 

Luckily the client was able to send us a log showing us what files were sent and at what date and time.  Helpfully, he highlighted the missing Sundays in yellow.  and all became clear.  The ones that worked were sent to us at various times ranging from about 0500 to 0700.  The ones that failed were sent to us at various times between 0700 and 0800. 
Guess when the Cron job runs?

The job to send us the data is automated - but runs when other things finish, hence the variety of times.  And Sundays?  "That's the day we bounce our servers..."

Untangle Database Names

Generally, when you set up a database, you call it 'SALESDB' or whatever, and that's the end of it.  The logical file names will default to SALESDB.MDF AND SALESDB_log.LDF, and so will the physical names on disk.  But over the years those names can get changed.  In my case I am in the middle of migrating databases from one system to another, and part of that involves changing the names which were created by a company which was taken over - you could consider it as airbrushing traces of the old system out of existence, I couldn't possibly comment. 

I found a good explanation in this MSSQLTip.    In their case, the project had changed and the old name was no longer relevant.  It could be a typo that irritates you enough to do something about it.  It could be that you are anally retentive enough that, like me, you like your database names to be consistent.  

Consistent?  Well, consider - the database name that you see every day isn't necessarily the underlying logical name of the database files.  Still less can you be sure that it is the name of the physical .mdf and .ldf files on disk.   Here's the Official word.  But what this means is that there can be three names - the name of the database, the logical name of the database files, and the physical name of the files on the disk.  They can all be different if you want them to be.

Caution - that way lies madness...

What I'll try to do in this post is untangle these various names and explain how to change them to be consistent.  SQL Server is reasonably easygoing as to what you call your database - but be sensible about it.  

First of all, get details of the database. The stored procedure sp_helpdb provides quite a lot of information about the database, (more than is shown here) but the results below are what we are interested in.  The name in square brackets is the name of the database.  Column 1 contains the logical names of the two database files.  Column 3 contains the physical names of the .mdf and .ldf files as they are found on the disk. Save this somewhere handy like an Outlook Task - you'll want to refer to it later. 

exec sp_helpdb [DQTHL]

DQTHL                 1              E:\MSSQL\Data\DQTHL.mdf

DQTHL_log          2              F:\MSSQL\Log\DQTHL_log.ldf

Let's all dance around singing halleluiah! Everything is consistent - the logical and physical names all match the database name.

If it was always so, there would be no point to this blog.  But it ain't like that all the time.  In a sense, it doesn't really matter - SQL Server would tolerate my next example, even though the database name doesn't match the logical file names, and the physical file names are something entirely unrelated.   It keeps track of what things are called and where they are.  The problem comes when a human being gets involved - maybe you want to do some housekeeping, and discover that the names don't tie up.  Humans are not good at telling which file belongs where, especially if there are lots of them, all with similar names. 

exec sp_helpdb [DQTHL]

  

DQ_Data                1              E:\MSSQL\Data\OldSales.mdf
DQ_log                  2              E:\MSSQL\Log\OldSales_log.ldf

OK, first step is to make sure that nobody else is doing something with the database.
You might get away without bothering, but you know what Sod's Law is like...

-- get exclusive access

alter database  [BEC_BASES]

SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Go

It's easy to change the database name - just right click on it and Rename is one of the options.  There's also a stored procedure you can use:

EXEC sp_renamedb 'old_name' , 'new_name'

 

However, I have a feeling that this is deprecated (meaning that Microsoft will wait until the most inconvenient time for you and then drop it).  Use Alter Database instead:

--Change DATABASE name

ALTER DATABASE  [BEC_BASES]

       MODIFY NAME = [BASES]

Go

Then we need to change the logical name of the files.  Remember we did sp_helpdb a few minutes ago?  This will give you the current names.  Almost always you will have an MFD and and LDF file,  but you could also have one or more NDF files as well, and in fact you can use any suffix you want. I came across a database where one of my predecessors had renamed the LDF file as MDF, so that there were two MDF files on the disk and no LDF files. 

Caution - that way lies madness...

-- Change Logical name

ALTER DATABASE [BASES] MODIFY FILE (NAME=N'BEC_BASES', NEWNAME=N'BASES')

GO

ALTER DATABASE [BASES] MODIFY FILE (NAME=N'BEC_BASES_log', NEWNAME=N'BASES_log')

go

Then we want to change the names of the physical files.  I used to Detach the database, change the file names, and then re-attach, and that's fine, but I think this way is actually easier.

Let go of the database (or you won't be able to do the next bit):

use master

go

Take the database offline

ALTER DATABASE BASES SET OFFLINE

GO

Tell it the file names that you are going to use:

ALTER DATABASE BASES MODIFY FILE (NAME = BASES, FILENAME = 'E:\MSSQL\Data\BASES.mdf')

GO

ALTER DATABASE BASES MODIFY FILE (NAME = BASES_log, FILENAME = 'F:\MSSQL\Log\BASES_log.ldf')

GO

The files are modified in the system catalog. The new path will be used the next time the database is started.

Now go to File Explorer or however you like to carry out operating system tasks like Rename.  I suppose in theory that you could do this with XP_CMDShell, but you would have to remember to enable it and then disable it again afterwards - more trouble than it's worth.

Navigate to the data folder and rename the MDF file, then to the log folder and rename the LDF file. 

Put the database back online

ALTER DATABASE BASES SET ONLINE

GO

Open up the access to everyone (remember you made it single user?)

ALTER DATABASE [BASES]

       SET MULTI_USER

And just to be sure that you have done everything right, run sp_helpdb again and check the results against your original:

exec sp_helpdb [BASES]

DQTHL                 1              E:\MSSQL\Data\DQTHL.mdf

DQTHL_log          2              F:\MSSQL\Log\DQTHL_log.ldf

We've untangled it!  Let's all dance around singing halleluiah!