Using XQuery to Process a Stored Procedure (Channel 9)

Using XQuery to Process a Stored Procedure

Posted: Oct 10, 2005 at 6:41 AM

By: trobbins

(1)

16,500 Views

2 Comments

Video format

Option selected may change based on video formats available and browser capability.

Auto

Use our suggested format for this video.

Smooth Streaming

Adaptive bitrate streaming - little buffering but lower video quality at times of low bandwidth. Silverlight 5 required

Progressive

Traditional buffered video format. Silverlight 5 required

HTML5

For browsers that support H.264 MP4 or WebM video playback such as:
IE9+, Firefox 4+, Chrome 5+, or Safari 4+.

Flash

For browsers that have the Adobe Flash Player plugin installed.

Follow the Discussion

Oops, something didn't work.

Try again?

Getting "follow" information

Stop following these comments

Start following these comments

Removing your "follow"

Setting up your "follow"

Subscribe to this comments

Hello,
Thanks for your comments. Smiley

Yes, some people don't like using DateTimes to identify the "Lost Update" problem. This is a concern when a higher level of precision is required than what is offered by the DateTime (i.e. you have very high concurrency with lots of updates within milliseconds of each other). An alternative that many find acceptable is to use the TimeStamp data type.

In any event, the primary concept here was really meant to be more about the neat things we can do with XQuery, and I do hope you found something useful there.

Concerning XQuery, a member of the SQL Server Engine team recently contacted me about a few issues which I either did not address (e.g. performance of Value() vs. Exist(), using XML or VarBinary data types for input parameters rather than TEXT, code page and encoding issues ), or was unaware of (e.g. potential data corruption attributable to code page and XML encoding). He graciously offered to write a post on these subjects for www.DesignPatternsFor.Net in the next month or two.

http://www.designpatternsfor.net/default.aspx?pid=33

Cheers,
Rob Daigneau

Follow
Oops, something didn't work.

Try again?

Sign In to be begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to this comments

gammaraytt

Dec 01, 2005 at 11:48 AM

i don't think using a date field to determine concurrency issues is a good practice.
RobDaigneau

Dec 05, 2005 at 12:21 PM

Hello,
Thanks for your comments.

Yes, some people don't like using DateTimes to identify the "Lost Update" problem. This is a concern when a higher level of precision is required than what is offered by the DateTime (i.e. you have very high concurrency with lots of updates within milliseconds of each other). An alternative that many find acceptable is to use the TimeStamp data type.

In any event, the primary concept here was really meant to be more about the neat things we can do with XQuery, and I do hope you found something useful there.

Concerning XQuery, a member of the SQL Server Engine team recently contacted me about a few issues which I either did not address (e.g. performance of Value() vs. Exist(), using XML or VarBinary data types for input parameters rather than TEXT, code page and encoding issues ), or was unaware of (e.g. potential data corruption attributable to code page and XML encoding). He graciously offered to write a post on these subjects for www.DesignPatternsFor.Net in the next month or two.

http://www.designpatternsfor.net/default.aspx?pid=33

Cheers,
Rob Daigneau

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.