Category: Uncategorized

I woke up this morning to find Tia reading an actual paper books. That’s become a rarity for both of us, each of us tending to read on our phones and not with real books.

I reached over and held her hand, just laying there. We do that a lot, and it’s very relaxing. I like holding my wife’s hand. I felt her move, and opened me eyes, and saw that she had tilted the book so she could read the right hand page and I could now see the title. I closed my eyes until a minute later when she said

“This is so inconvenient”

She was referring to the fact that she had to hold the book up, it’s heavy, no light for night reading, and she can’t turn pages with one hand. At least not easily.

I’d agree with most of those, and reading in bed was one of the main reasons I like e-reading. I can do it with one hand, I don’t disturb my wife, and it was easy. I had all my books with me, and enjoyed it. With the Kindle I needed a reading light, but with the iPhone I don’t, and in that sense it’s superior. It’s also smaller, lighter, and one less thing to carry.

On the other side, I can’t easily read in bright sunlight, and I wonder how my trip to the islands will go. I am planning on taking 4 or 5 paper books along that have been sitting on the shelf and I want to get through. This is a great time to do it, plus being gone for 6 days, and not sure about my Internet connection, I don’t want to spend $100 or so on books.

The book my wife had was one our son recommended, and she said she’s just going to buy it from B&N to make things easier.

Still no work on my laptop. It’s been over 24 hours since I left a message for the customer escalation team and no return call. I haven’t tried to call them back because, well, I’ve been busy. Trying to get things done to get off on vacation next week has me jammed up. I should have some time tomorrow to call and I’ll see what happens then. I’d like to record the call, but we’ll see how that goes.

A few people have asked why don’t I threaten Toshiba with a mention in my newsletter going out to hundreds of thousands of people? Why don’t I play that card to get some service? I haven’t done it, but the story, or at least a take on it, is going out in tomorrow’s editorial as Dodge, Dip, Dive, Duck, and Dodge.

I have a few reasons why I haven’t done that.

1. I’d feel like an ass if I did
2. I don’t want or like special treatment
3. I want to know what Toshiba will do for everyone else.

I don’t really like special treatment, or being recognized. I guess I’m still a little shy, but I also don’t really think I’m any better than anyone else. Someone who pulls the “do you know who I am?” when they get in trouble always bothers me and I don’t want to be the one doing that. So I don’t threaten, or mention my job, in cases like this.

There’s also a curiosity factor. If I wasn’t able to communicate to lots of people, how would I get treated? Or how will everyone else get treated? I was irate, and still am, but I wanted to get the regular guy experience. Heck, I might be a regular guy that doesn’t write a daily column at some point.

So I’m now just wondering what will happen. Tomorrow I’ll actually order something else, hoping that it will arrive by the time I get back from vacation.

I never liked GUIDs, not really using them in most of my development until I had a conversation many years ago with Andy Warren. At the time he was working for a company as a development manager and building in house applications. We were debating the ways in which we built applications, me mainly using web technologies, and him still using client-server technologies at a call center. We debated the various pros and cons of both methods, and one thing he said stuck with me for many years.

At the time I often used (and still do use) identities as the surrogate and PK of many of my tables. That’s another debate, and I don’t want to digress here. Instead I wanted to point out an interesting item that Andy explained to me years ago about the advantages of GUIDs over identities.

The client can create them.

That’s pretty interesting, especially in cases where you need to insert a parent and a few child records from a remote machine. You can create the parent record, and child records, without a round trip to the database, and still have them related. That’s something that isn’t easy to do with identities, and it could easily cause lots of breakage in your client applications.

An identity is generated on the server. You insert a row, you then use @@scope_identity, not @@identity, to retrieve the identity of the inserted row. You can then use that and insert it in your child records. It’s quick, clean, and it often follows the workflow for an application.

However a GUID, which is supposed to be unique (it isn’t always), can be generated on the client. A client can’t generate an identity since it can’t be sure of the concurrency issues with other clients. A GUID can be built on the client, it’s likely unique, and so the client can already know the surrogate key for the parent, thus the FK for the child rows, and send all that back with a minimum of round trips to the server.

There are different ways to create a GUID on the client, depending on your technology, but they all essentially work the same as the NEWID() function in SQL Server. You’d have to look for a function or API depending on your client technology to do this.

It’s an interesting idea, especially with disconnected clients, which might need to update a local database of some sort, and then have that replicated or sync’d with a master database later. By using GUIDs for the surrogate keys, you don’t need to set aside ranges of identities, or worry about collisions for the most part. Just be aware there could be issues, and this StackOverflow question highlights some of the issues.

Adam Machanic started the idea of a blog party last month, getting people to write about date and time issues in SQL Server. This month he’s asking for a puzzling situation, and I had a little time, so I decided to oblige.

I’ve done a lot of different things in SQL Server over the years, but this particular situation is one that stumped me for awhile. And I’m not the only one as I see this question posted on a regular basis and the answer typically is similar to what I used to solve my problem.

Years ago I was working for a small company, receiving regular data feeds from vendors that required us to load and update our list of products. We sold education based products, and as the cost, name, etc. changed from Vendors, we had to update our data.

So I had a table that was something like this one. This is simplified for the sake of the example.

CREATE TABLE MyTable
( id INT,
  PONumber VARCHAR(20),
  Cost NUMERIC(10,4)
  )

One day I had to run an update statement like this one to fix a product. It was a simple update that would correct a simple product:

UPDATE dbo.MyTable
SET Cost = 56
WHERE PONumber = 24

and I got this:

Msg 245, Level 16, State 1, Line 2
Conversion failed when converting the varchar value ’24 A’ to data type int.

Huh? I’m updating a specific product, and while the data types are different, this ought to be easily handled by the engine. I tried this same statement a few ways, and it kept failing.

I see many people running into this, and not understanding why it fails. After a few hours of working through this I eventually realized what was happening.

There is an implicit conversion occurring here because the data type of the PO number is a varchar, meaning that the value is

’243’

‘24’

etc.

and it’s being compared, or converted, to an int to match the 24 integer in the WHERE clause. If you examine the implicit conversion table in the CAST and CONVERT BOL entry, you’ll find that this is indeed an implicit conversion.

Does order matter? No. This returns the same error.

UPDATE dbo.MyTable
SET Cost = 56
WHERE 24 = PONumber

Why isn’t 24 converted to ‘24’ and compared? I think it has to do with data type precedence, in which int has a higher precedence than char (or varchar), so the conversion takes place with the column being converted to 24, an integer.

I fixed this by changing my query.

UPDATE dbo.MyTable
SET Cost = 56
WHERE PONumber = ’24’

That removed the conversion, and things worked.

Knowing your implicit conversions is important. It’s a basic thing, but you ought to have an idea of when they occur, and you ought not to depend on them. This should be something you keep in mind, and make it like the printer power cord: check it first.

Happy T-SQL Tuesday!