MacLochlainns Weblog

Michael McLaughlin's Technical Blog

Site Admin

Archive for February, 2019

iPhone & Snowblower

without comments

What happens when your 16 year old doesn’t know he has a hole in his pocket, the iPhone slips down his pant leg unnoticed, and he runs over the device with a snowblower. It’s called instant shredded iPhone. You think that’s bad news but that’s why I purchased AppleCare for the device.

Then, you call Apple and discover that unless they can find and read the IMEI number from a chip, there is no warrantee coverage. That tells me AppleCare is worthless against EXTREME damage. It’s only of value when you drop it and break something while the unit remains more or less intact, or you have one of the growing number of iPhone’s with manufacturing defects that you can’t catch within the first year of ownership.

After three calls to Apple, the “senior” technical analyst said you can bring it into the local Apple Store. At that point, I asked, “Did you fail to hear that I live over 250 miles away from the nearest Apple Store?” The analyst said, “Yes, I didn’t hear that.” It was obvious that the situation didn’t fit inside the box that let them close the issue and move on with positive outcome on their staff metrics.

What Apple would like is: The customer pays $99 to replace the phone while they evaluate the pieces to see if they can find an IMEI number. They probably have that policy to avoid fraud on broken iPhones. If they can’t find an IMEI number though, they get to charge full price for the replacement iPhone. I opted for an alternative: they send me a box, I enclose the pieces for evaluation before pay $99 for a replacement iPhone, assuming they can verify from what’s left its was once an iPhone. This way, I can avoid getting soaked for the retail price when my plans support a less expensive upgrade of the now defunct device.

Ultimately, the likelihood of any value from AppleCare appeared to only occur when you break it without destroying it. However, I was wrong because Apple replaced the iPhone. 🙂

Written by maclochlainn

February 28th, 2019 at 6:02 pm

Variable Scope

without comments

Microsoft SQL Server provides T-SQL with the ability to assign values from the queries to local variables. While T-SQL returns a SELECT-list, there are rules for how you can assign the SELECT-list values. The process is more or less an all or nothing approach when assigning values to a local variable. The rule is quite simple for scalar variables because the SELECT-list may contain multiple values but assignments must be made one at a time. You can’t mix retrieving values with assignments. Lets say you try to write the following block of T-SQL code:

1
2
3
4
5
SELECT 'Execution Scope' AS "Statement";
DECLARE @base NVARCHAR(MAX) = N'';
WITH x AS (SELECT 'Chilly' AS cold, 'Burning up' AS hot)
SELECT @base += cold, hot FROM x;
SELECT @base AS "Result";

You raise the following exception:

Msg 141, Level 15, State 1, Server DESKTOP-4U7EN27, Line 3
A SELECT statement that assigns a value to a variable must not be combined with data-retrieval operations.

You should rewrite the query like this:

1
2
3
4
5
SELECT 'Execution Scope' AS "Statement";
DECLARE @base NVARCHAR(MAX) = N'';
WITH x AS (SELECT 'Chilly' AS cold, 'Burning up' AS hot)
SELECT @base += cold FROM x;
SELECT @base AS "Result";

While the subquery on line 3 returns a multivalued SELECT-list, the assignment statement appends the value associated with the column name or alias, which acts like a key in a dictionary. While a dictionary is a collection of name and value pairs, you can use the name of any dictionary element as a key to return only one value from the dictionary. That is the value that the name identifies in the dictionary.

You can put a GO on line 6 in an interactive session or you can put the five lines into a T-SQL script file and call it from the sqlcmd utility. You can run the script file with the following syntax, assuming you have a student user with student as its password working against items in the studentdb schema:

sqlcmd -Ustudent -Pstudent -dstudentdb -y40 -itestScope.sql -otestScope.out

Effectively, all T-SQL variables are limited to their execution scope. You determine execution scope interactively by providing the GO command. T-SQL script files are bundles that execute in a single execution scope unless you embed the GO command.

Then, you can display the testScope.out file as follows from the command line (in a cmd session):

type testScope.out

It will display the following:

Statement
---------------
Execution Scope
 
(1 rows affected)
Result
----------------------------------------
Chilly
 
(1 rows affected)

As always, I hope this helps those looking for a solution.

Written by maclochlainn

February 15th, 2019 at 10:34 pm