They can't predict the local weather for the next day, but Global Warming is an absolute certainty. What's wrong with this picture?

XQuery has now reached standardization by the W3C. The XML Team at Microsoft is now asking for input on whether there should be a standalone XQuery implementation in the .Net Framework in their blog entitled Standalone XQuery Implementation in .NET?.

 

My posted response is below:

I, also, would like to see an XQuery implementation within the .Net Framework.

If available, I would be more inclinded to use XQuery over XSLT, particularly in a more dynamic setting to extract data, and then to shape the output before consuming within an application.

While the XQuery implementation in SQL Server 2005 is excellent, it is still only a subset of the standard, for example, the ability to query against multiple documents. And, I would prefer to see the implementation as native to the .Net Framework, rather than as a commercial add-on.

 

The differences between what could be and what is available now are two fold. First, the current implementation resides on server-side, within the SQL Server itself. A .Net Framework (System.XML.XQuery) implementation would allow the developer to choose where the query would be executed. Additionally, you would be able to query across multiple documents, which you cannot do in the SQL Server 2005 version.

I have found the XQuery syntax to be easier to craft to extract XML content and shape the output than using XSLT. I think there is a strong incentive to have the XQuery implementation because it can provide some features that may either be missing or are easier to use than SQL Server XQuery, LINQ or XSLT.

I vote "Yes" to XQuery in the .Net Framework.

 

 

I just finished reading Joshua Trupin's editorial (Editor's Note) in the latest MSDN magazine, entitled "Bring On the Swag". It is not yet available on line - I just got it in my March 2007 edition.

Joshua's article is a humurous discussion centering corporate give-aways, blogs, and the issue of credibility. I enjoyed his discussion immensely, and highly recommend it. For those of you, like me, that have attention deficit syndrome, the article is a good, quick read!

In the article, he laments that his reviewers don't get anything good to review. But I am sure he gets to see more of the new (coming soon) Microsoft technology, and earlier, than I do.

Well Joshua - I hope you get all the Zunes and Wide-Screen TVs you all can handle. Just remember there are people, like me, that are a little farther down the Microsoft food chain that envy your access to Redmond.

 

 

Often, in development, we will take a backup of a database from one SQL Server to another. Perhaps we are moving a database to our development environment to do some local debugging.

Invariably, if you use a backup/restore process, you have an orphaned database "user" account that you need to map to a login. I have done this several times, but I keep forgetting the command, so I thought I would blog it so that I won't forget it, and perhaps others would benefit from this information.

Assume your database that you restored has a user, called "appUser", that is used by some application that accesses that databasde. Use the following steps to match a login account to the database user.

1. Create a login account, if there is not one, in this case create a SQL Server login "appLogin" (In this case we are creating a database login account, not a Windows account. But it is just as easy to do the same thing with a Windows account).
2. Execute the following command:

EXEC sp_change_users_login 'Update_One', 'appUser', 'appLogin';

GO

That's it. Pretty easy. Make sure to check the login and user to ensure that this login/user can access the database.

You can check the details out at the Microsoft SQL Server Books-On-Line for sp_change_users_login.