It seems like there is a 'bug' in Netscape 8 where it kills Internet Explorer's ability to render XML documents.
You really have to ask whether it was intentionally harming IE's functionality when the situation is caused by constantly changes a registry entry that should (under normal programming courtesy) by owned by IE. I like how the fix is to remove Netscape 8. Can Netscape be sued over something like this?
For the last month, I have been taking a break from developing the skinning engine. Instead of working on the skinning engine, I have been putting my focus into developing a feed reader application as I am not happy with the readers currently available. There has always been a particular feature or lack thereof that I didn't like, and my current one has become unreliable. I hope to have a Beta version available sometime in the next month or two depending on the time available.
On a similar note, I have fixed a bug in the RSS feeds on the site where there were three non-standard characters being put at the start of the feeds.
I have just realised a personal/social problem that could result from RSS. RSS (and the other feed types) have really changed the way people use the internet. So much of the information we are interested in comes straight to us instead of us constantly seeking it out.
I remember a couple of years ago, I checked a particular code site for updates basically each day, but it didn't get updated for around a year and a half. I was really keen (obviously) for new content. From the time at which I kicked off the browser to the time that I realised nothing had changed, I was kind of happy about the possibility that there might be something new posted. After a year and a half, I was quite certain that the site wouldn't have changed, but the possibility was a comforting thought.
Now that most places use RSS, I already know that there is nothing new. It is kind of like being disappointed even before you have a chance to get excited that there might be something new. RSS induced despair might become a new topic when training therapists.
I have been thinking for a couple of weeks that email over RSS would be a great idea. I would like to do this because at work the firewalls block port 110 which forces me to use webmail. I would love to develop something like this myself (yet another side project to the current side project....), but I think it is time to use something that someone else has developed for once.
The feed revolution continues with pop2rss.
I have used XML queries in SQL Server for several years now and I am very impressed with the changes to FOR XML in the latest SQL Server 2005 beta. Unfortunately, there doesn't seem to be much changed in the OPENXML arena.
I was working with an OPENXML statement the other week and I was sick of writing WITH clauses to define how to interpret the XML data. I looked at the documentation for the WITH statement and discovered that you can specify an existing table and use its schema to interpret the XML.
This was great news as I shape my XML data in a way that is consistent with the table schema that stores the data in the database. I wanted to just specify the table that the data was related to. This prevents having to manually type the schema in the WITH clause and also means that if the schema of the real table changes, namely field size or type changes, the procedures don't need to be updated unless fields are removed or added.
Here is where I hit the snag. My tables typically have a primary key that is an INT IDENTITY and WITH clauses will not work with these. What is happening here is that when with WITH clause in OPENXML uses a table scheme, it skips IDENTITY fields when it interprets the XML.
I guess the argument is that INT IDENTITY fields are not modifiable (without intentionally disabling the constraint with SET IDENTITY_INSERT), therefore why allow it to be seen in interpreted XML. The designers must have thought that people might try to insert these values into an IDENTITY field if they allowed us to see the values in the XML. I think they really should have given the developer the choice though. Besides, OPENXML is about reading data, not writing it.
Here is a test script to illustrate what I mean.
DECLARE @sXML NVARCHAR(4000)
DECLARE @hDoc INT
SET @sXML = '
<Root>
<Item>
<Key>1</Key>
<Test1>A</Test1>
<Test2>A2</Test2>
</Item>
<Item>
<Key>2</Key>
<Test1>B</Test1>
<Test2>B3</Test2>
</Item>
<Item>
<Key>3</Key>
<Test1>C</Test1>
<Test2>C4</Test2>
</Item>
<Item>
<Key>4</Key>
<Test1>D</Test1>
<Test2>D5</Test2>
</Item>
</Root>
'
CREATE TABLE #tabletest
(
[Key] INT IDENTITY(1, 1),
Test1 NVARCHAR(50),
Test2 NVARCHAR(50)
)
EXEC sp_xml_preparedocument @hDoc OUTPUT, @sXML
SELECT *
FROM OPENXML (@hDoc, '/Root/Item', 2)
WITH #tabletest
EXEC sp_xml_removedocument @hDoc
DROP TABLE #tabletest
In this example, only the Test and Test fields are returned. Key, being the INT IDENTITY, is ignored.
You may notice that I used a temporary table in the WITH statement. WITH statements won't work with table variables. My original intention here was to use my permanent table for the WITH clause, but then there is this IDENTITY problem. It is unfortunate that this situation forces more redundant code to be written and code that is not flexible to changing schema's.
The way I write these procedures is to define a temporary table (like the above example) that has the same schema as the permanent table but without the IDENTITY declaration. This means that I can use the temporary table to not only provide a schema for the XML, but also insert the records from OPENXML into that table. This then allows me release the XML document handle and work with normal TSQL statements.
The way I would use the above code would be something like this:
DECLARE @sXML NVARCHAR(4000)
DECLARE @hDoc INT
SET @sXML = '
<Root>
<Item>
<Key>1</Key>
<Test1>A</Test1>
<Test2>A2</Test2>
</Item>
<Item>
<Key>2</Key>
<Test1>B</Test1>
<Test2>B3</Test2>
</Item>
<Item>
<Key>3</Key>
<Test1>C</Test1>
<Test2>C4</Test2>
</Item>
<Item>
<Key>4</Key>
<Test1>D</Test1>
<Test2>D5</Test2>
</Item>
</Root>
'
CREATE TABLE #tabletest
(
[Key] INT,
Test1 NVARCHAR(50),
Test2 NVARCHAR(50)
)
EXEC sp_xml_preparedocument @hDoc OUTPUT, @sXML
INSERT INTO #tabletest
SELECT *
FROM OPENXML (@hDoc, '/Root/Item', 2)
WITH #tabletest
EXEC sp_xml_removedocument @hDoc
-- Use the records in #tablets
SELECT *
FROM #tabletest
DROP TABLE #tabletest
Microsoft Update - Now this is a good idea. I have often thought about why Windows Update only updates Windows. Apart from the obvious, being its name, I think Microsoft should have provided a common update service for all of its products years ago.
Microsoft Update (which is currently in Beta version) will update Windows, Office and some server software. I think it is safe to assume they will expand this service to support for of their applications, although most people will only need it for Windows and Office. It is good that there is now one less action for me to take to get updates.
This one just went around the office. Couldn't resist posting it.
After digging to a depth of 100 metres last year, Russian scientists found traces of copper wire dating back 1000 years, and came to the conclusion that their ancestors already had a telephone network one thousand years ago.
So, not to be outdone, in the weeks that followed, American scientists dug 200 metres and headlines in the US papers read:
"US scientists have found traces of 2000 year old optical fibres, and have concluded that their ancestors already had advanced high-tech digital telephone 1000 years earlier than the Russians."
One week later, the Australian newspapers reported the following:
"After digging as deep as 500 metres, Australian scientists have found absolutely nothing. They have concluded that 5000 years ago, their ancestors were already using wireless technology."