Showing posts with label curious. Show all posts
Showing posts with label curious. Show all posts

Tuesday, March 27, 2012

Does SQL Server 2005 Express support XQuery Static Type Analysis?

I am quite curious about SQL Server 2005 Express, since I am conducting an XQuery implementation survey for my thesis study.

Yet I still got some questions and may need your help:

1. Does SQL Server 2005 Express support XQuery static type analysis (from http://www.w3.org/TR/xquery-semantics/)?

2. If so, since the W3C standard is still changing, how do you keep up
with the change efficiently?

Your help will be appreciated.
Happy New Year and Thank you,

Selina, Wang

hi Selina,

SQL Server 2005 XQuery implementation is alligned with the July 2004 Working Draft of XQuery http://msdn2.microsoft.com/en-us/library/ms345122.aspx ...

when using a specific tool, you can and obviously should be concerned with the changing stages, but should focus on the actual implementation "as is" for the day by day uses..

regards

Wednesday, March 21, 2012

Does RAISERROR cause performance to go down slightly?

I was curious if using RAISERROR in the catch block of a stored procedure does actually causes some hit on performance? I think it would, as compared to simply returning an error code in this sp's output parameter.

It will cause some impact as RAISEERROR will inevitably require some extra resource, where as you rightly say an error code just requires a value to be set within an existing block of memory.

Friday, February 24, 2012

Documenting triggers

I believe in avoiding triggers whenever possible. However, in the
circumstance that a trigger is the "right" solution, I'd be curious how
people document/diagram triggers so that a successor could actually find
them aside from just having a document that says "by the way, there are some
triggers on these tables ...". That's the type of document that will be
lost/forgot about in a hurry. Moreover, triggers don't fall nicely into the
graphically easy to find categories of tables, views, stored procedures,
etc..
Thanks in advance for your suggestions.
MarkThere is no way to do this in SQL Server (only through quering the
information_schmea /systables), but if you have Visio you can easily load
them from your database via Reverse Engineering. Thats the way a documenting
i use, because if something changes i just "reload" the database in Visio
and Voil.
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"Mark" <Mark@.nowhere.com> schrieb im Newsbeitrag
news:ue%23F8noSFHA.3188@.TK2MSFTNGP09.phx.gbl...
>I believe in avoiding triggers whenever possible. However, in the
>circumstance that a trigger is the "right" solution, I'd be curious how
>people document/diagram triggers so that a successor could actually find
>them aside from just having a document that says "by the way, there are
>some triggers on these tables ...". That's the type of document that will
>be lost/forgot about in a hurry. Moreover, triggers don't fall nicely into
>the graphically easy to find categories of tables, views, stored
>procedures, etc..
> Thanks in advance for your suggestions.
> Mark
>|||See if this helps:
Schema: How do I show all the triggers in a database?
http://www.aspfaq.com/show.asp?id=2105
AMB
"Mark" wrote:

> I believe in avoiding triggers whenever possible. However, in the
> circumstance that a trigger is the "right" solution, I'd be curious how
> people document/diagram triggers so that a successor could actually find
> them aside from just having a document that says "by the way, there are so
me
> triggers on these tables ...". That's the type of document that will be
> lost/forgot about in a hurry. Moreover, triggers don't fall nicely into t
he
> graphically easy to find categories of tables, views, stored procedures,
> etc..
> Thanks in advance for your suggestions.
> Mark
>
>