Showing posts with label Microsoft. Show all posts
Showing posts with label Microsoft. Show all posts

Friday, May 11, 2012

Inconsistent Line Ending Style

In trying to commit some changes to SVN using the TortoiseSVN client, I received an odd error for a single SQL database table script text file:

Inconsistent line ending style


On the TortoiseSVN forums someone suggested that this might have occurred because someone edited the file in multiple editors, and somewhere in the process happened to slip in a line feed particular to their editor which version 1.7.4 of our Apache Subversion server found disagreeable.

To work around this, I was able to open the file in Microsoft Word, then save the file as plain text, with Windows (Default) chosen for text encoding:



Why SVN server scrutinizes the line feeds is unclear to me, but thankfully whomever committed the offending change made it to just this one file out of hundreds in the repository.





Wednesday, June 16, 2010

Long Live the Classic Start Menu!

At work, I have finally received a brand-spanking new Dell Latitude E6410 laptop, complete with Windows 7 Pro.

I'm certainly loving the speed so far. As you might expect, stuff that seemed to take ages with XP goes blazingly fast under 7.
 

But, what's this?? Where's my beloved CLASSIC START MENU???

Apparently, Microsoft believes that since time marches on, all Windows users shall march in cadence with it. Some fanboys, too, wonder why all us holdouts don't simply drop the crude old Classic start menu altogether.

Absurd!

While I'm certainly happy for those who've enjoyed the new start menu, I for one would much rather keep the venerable Classic menu. I'm accustomed to it, I'm comfortable with it, and frankly, I don't really see a real need to switch.

Classic
works for me.

Along those lines, I've found ClassicShell. The creators of this add-on compatible with Windows 7 allows users to once again have their Classic start menu available.

Please, don't get me wrong, I'm certainly all for innovation and efficiency. However, is it truly more efficient to force users to become accustomed to a new start menu, and eliminate one that a significant number of users have been comfortable with for years? 




Isn't it more innovative to allow users to maintain their own customizations and preferences, despite changes in the underlying operating system? Personally, I'd like to keep my grubby paws on the Classic start menu as long as I can, because frankly I don't care to explore the new start menu which Microsoft slaps upon Windows 7 users.

In my humble opinion
, Microsoft would do well to ensure that their underlying OS works like a charm, and leave users to enjoy the preferences that they have come to enjoy, nay, expect, from their products.

Thursday, February 11, 2010

Automatic Updates Strikes Again!

Visual Studio 2008, greeted me with this message:

Cannot find one or more components. Please reinstall application.


I awoke this morning to discover that Automatic Updates had happily updated and rebooted my laptop. Fine, whatever. I'd saved my important stuff before turning in last night, so no big deal, just annoying... except for the part where it seemingly destroyed my completely legal and presumably up-to-date install of VS 2008.

Fortunately after some digging I found a solution here, which basically involves recovering at least one DLL (in my case, ATL90.DLL) and copying it to a folder with a name similar to "C:\WINDOWS\WinSXS\x86_Microsoft.VC90.ATL_1......"

The actual destination folder appears to include a build number, so maybe whoever at Microsoft released this latest update to the masses simply forgot to include this essential little file in the update?

I found some of the other missing DLL names amusing. IESHIMS.DLL, for example, includes the word "shim", which in engineering parlance is "...a thin and often tapered or wedged piece of material, used to fill small gaps or spaces between objects," but in computing is "...a small library that transparently intercepts an API, changing the parameters passed, handling the operation itself, or redirecting the operation elsewhere." WER.DLL contains wer, which is in German a pronoun for "who".

Speculation abounds. Who will we pick from our resource pool to fix this, someone who knows their shit, or a convenient intern instead? I wonder if our team lead would like a shim shoved where the sun don't shine to facilitate following some semblance of best practices?

This cries out as a leftover hunk of code that maybe someone at Microsoft slapped together years ago and put it on their little Post-It™ of a todo list to tidy up, which happened to be close to the shredder, which also happened to be in an office with a ceiling fan set on ludicrous speed or a cat with an affinity for ink and paper.

Or, maybe the original developer given the task to do this was killed in a fatal car crash, never to replace the shim with something more... elegant.

Now I'm asking Microsoft the question, who shimmed on my work, and how may I smite them?


3/8/2010 - UPDATE

A user in the forum thread I mention above was able to reinstall the following Microsoft security update and successfully dig themselves out of the pit of despair this error caused:


Microsoft Visual C++ 2008 Service Pack 1 Redistributable Package ATL Security Update

GHFBHMX20410479



Friday, January 2, 2009

Extend Existing XML Parsing to Support Multiple Child Tags

I work on a database which is currently a mix of Microsoft SQL 2000 and 2005 T-SQL code. As part of a project I’m working on, I'm working with a stored procedure which receives a reference to an XML document in the form of an integer variable @idoc, and this XML document’s structure needs to be extended with some additional elements.

I'd prefer to refactor the plumbing which generates the XML in the remote stored procedure so that I can take advantage of the new XML data type in 2005, which would allow me to simply pass the XML as a parameter to my stored proc, but unfortunately time is of the essence, so I need to develop an alternative which doesn't involve refactoring to that extent.

The current XML resembles the following:

<XML>
<AccountInfo
Number="123456789"
Status="Active"
Region="SE" />
</XML>


The new XML will look like this:

<XML>
<AccountInfo
Number="123456789"
Status="Active"
Region="SE" />
<State>
<StateInfo
Name="Florida"
Population="9488294"
AreaSquareMiles="58560"
LandAreaSquareMiles="54252"
WaterAreaSquareMiles="4308" />
<County
Name="Alachua"
Population="277120" />
<County
Name="Union"
Population="14842" />
</State>
</XML>


The stored procedure which I need to modify for my project receives the pointer to the XML document, @idoc, and after extracting values from it makes various other calls to other stored procs.

A new State element is being added, with a child StateInfo element that describes the state in question, and any number of child County elements describing counties in that state. In other words, this XML describes an account, the state it operates in, and however many counties the state contains which are relevant to a given account.

My major challenge with this is in the form of the new County tags. Whereas previously there would only ever be a single instance of any particular tag in this XML, there could potentially be dozens of County tags associated with a given State for an account! For each County I need to be able to iterate through the collection and provide these details somehow to my stored procedure for further processing.

My work is pretty well cut out for me. I need to find a way to:
  • Rebuild the XML document using the @idoc as a reference.
  • Grab the new XML specific to each County tag and serialize the values.
To reproduce the XML in the state my stored procedure will be consuming it, I first needed to generate my own @idoc using sp_xml_preparedocument like this:

DECLARE @TestXML varchar(4000)
DECLARE @idoc int

SET @TestXML = '<XML>
<AccountInfo
Number="123456789"
Status="Active"
Region="SE" />
<State>
<StateInfo
Name="Florida"
Population="9488294"
AreaSquareMiles="58560"
LandAreaSquareMiles="54252"
WaterAreaSquareMiles="4308" />
<County
Name="Alachua"
Population="277120" />
<County
Name="Union"
Population="14842" />
</State>
</XML>'

EXEC sp_xml_preparedocument @idoc OUTPUT, @TestXML


At this point, @idoc is a reference to an accurate representation of the XML structure my stored proc will receive and process.

As I mentioned, the code outside of the scope of my stored proc is SQL 2000 based, but that doesn’t mean I can’t use some of the great new capabilities in 2005 in my code. Thus, here I use the OPENXML command to crack open the XML, in conjunction with the FOR XML PATH directive to build the XML structure.

-- First build the XML to give @idoc a reason to live.
EXEC sp_xml_preparedocument @idoc OUTPUT, @TestXML

SELECT
(
SELECT Number, Status, Region
FROM OPENXML(@idoc, '/XML/AccountInfo', 1) WITH (
Number int,
Status varchar(100),
Region varchar(2)
) AS StateInfo FOR XML PATH('AccountInfo'), Type
),
(
SELECT
(
SELECT Name,
Population,
AreaSquareMiles,
LandAreaSquareMiles,
WaterAreaSquareMiles
FROM OPENXML(@idoc, '/XML/StateInfo', 1) WITH (
Name varchar(100),
Population int,
AreaSquareMiles int,
LandAreaSquareMiles int,
WaterAreaSquareMiles int
) AS StateInfo FOR XML PATH('StateInfo'), Type
),

(
SELECT Name,
Population
FROM OPENXML(@idoc, '/XML/County', 1) WITH (
Name varchar(100),
Population int
) AS County FOR XML PATH('County'), Type
)
FOR XML PATH('State'), Type
)
FOR XML PATH('XML')

-- Eliminate the document.
EXEC sp_xml_removedocument @idoc


Here is the output from execution of the above code. I’m done… right??

<XML>
<AccountInfo>
<Number>123456789</Number>
<Status>Active</Status>
<Region>SE</Region>
</AccountInfo>
<State>
<StateInfo>
<Name>Florida</Name>
<Population>9488294</Population>
<AreaSquareMiles>58560</AreaSquareMiles>
<LandAreaSquareMiles>54252</LandAreaSquareMiles>
<WaterAreaSquareMiles>4308</WaterAreaSquareMiles>
</StateInfo>
<County>
<Name>Alachua</Name>
<Population>277120</Population>
</County>
<County>
<Name>Union</Name>
<Population>14842</Population>
</County>
</State>
</XML>


Hmmm, not quite. Notice that there are separate tags beneath AccountInfo, StateInfo and County. Whereas my prototype XML has the values under these tags in the form of XML attributes, they appear here as tags. Not good!

I found an article by Jerry Dixon which led me to the answer. I just needed to take each item in my SELECT statements and use AS ‘@<attributeName> to tell SQL to output the item as an attribute of the node rather than a separate element.

EXEC sp_xml_preparedocument @idoc OUTPUT, @TestXML

SELECT
(
SELECT Number AS '@Number',
Status AS '@Status',
Region AS '@Region'
FROM OPENXML(@idoc, '/XML/AccountInfo', 1) WITH (
Number int,
Status varchar(100),
Region varchar(2)
) AS StateInfo FOR XML PATH('AccountInfo'), Type
),

(
SELECT Name AS '@Name',
Population AS '@Population',
AreaSquareMiles AS '@AreaSquareMiles',
LandAreaSquareMiles AS '@LandAreaSquareMiles',
WaterAreaSquareMiles AS '@WaterAreaSquareMiles'
FROM OPENXML(@idoc, '/XML/State/StateInfo', 1) WITH (
Name varchar(100),
Population int,
AreaSquareMiles int,
LandAreaSquareMiles int,
WaterAreaSquareMiles int
) AS StateInfo FOR XML PATH('StateInfo'), Type
),

(
SELECT Name AS '@Name',
Population AS '@Population'
FROM OPENXML(@idoc, '/XML/State/County', 1) WITH (
Name varchar(100),
Population int
) AS County FOR XML PATH('County'), Type
)

FOR XML PATH('XML')

EXEC sp_xml_removedocument @idoc


Now my rebuilt representation of the original XML document, reconstructed using @idoc as a reference, is just the way I need it to be:

<XML>
<AccountInfo Number="123456789" Status="Active" Region="SE" />
<State>
<StateInfo
Name="Florida"
Population="9488294"
AreaSquareMiles="58560"
LandAreaSquareMiles="54252"
WaterAreaSquareMiles="4308" />
<County Name="Alachua" Population="277120" />
<County Name="Union" Population="14842" />
</State>
</XML>


The next requirement, how to serialize only the County values tied to each account? I can use some of the code which reconstructs the County nodes, above, and omit the AS and FOR XML PATH(‘County’), Type syntax so that a result set rather than XML is returned:

   SELECT Name, Population
FROM OPENXML(@idoc, '/XML/State/County', 1) WITH (
Name varchar(100),
Population int
)


Here’s the result set output by the SELECT:


   Name          Population

Alachua 277120
Union 14842


I defined a table variable to hold the County values, along with its own autoincrementing ID (just because it’s handy to have a unique identifier for other stuff happening in my stored proc).


DECLARE @County TABLE
(
ID int IDENTITY (1, 1) PRIMARY KEY NOT NULL,
Name varchar(100),
Population int
)


Finally, I populate the table variable with the County data I extract from the XML:


INSERT INTO @County (Name, Population)
SELECT Name, Population
FROM OPENXML(@idoc, '/XML/State/County', 1) WITH (
Name varchar(100),
Population int
)


In summary
, I’ve created code which extends the stored procedure so that it can handle multiple instances of a tag, whereas previously it was built to expect only a single instance of each tag. This enables me to properly recombobulate, if you will, the original XML passed by reference from a remote stored proc, then serialize all instances of the new tag and mess with them elsewhere in my code.


___

Special thanks to Greg Houston and his article Format My Source Code For Blogging which helped me compensate for difficulties I had with formatting my code.