> I was looking at the code in sp_updatestats. I had an ideas about using some
> of the logic in a custom script.
>
> I thought that I would start by creating a copy of sp_updatestats. That was
> not so easy. I get this error message.
>
> Msg 195, Level 15, State 10, Procedure sp_updatestats2, Line 120
> 'stats_ver_current' is not a recognized built-in function name.
>
> Does anyone know what kind of an object stats_ver_current is?
>
> I'm also interesting in what it is that it's doing. In the comment it says
> like this, but I'm not sure what it means.
>
> -- also, force a refresh if the stats blob version is not current
>
> Ola Hallengren
> http://blog.ola.hallengren.com

"Aaron Bertrand [SQL Server MVP]" wrote:

> It exists in the resource database and is not accessible to us mere peons
> (it can only be executed in the context of a system procedure).  You will
> find several such functions across various system procedures...
> 
>
>
>
>
> On 6/24/09 4:23 PM, in article
> 360B5B47-B507-4418-B363-108776CEE***@microsoft.com, "Ola Hallengren"
> <OlaHalleng***@discussions.microsoft.com> wrote:
>
> > I was looking at the code in sp_updatestats. I had an ideas about using some
> > of the logic in a custom script.
> >
> > I thought that I would start by creating a copy of sp_updatestats. That was
> > not so easy. I get this error message.
> >
> > Msg 195, Level 15, State 10, Procedure sp_updatestats2, Line 120
> > 'stats_ver_current' is not a recognized built-in function name.
> >
> > Does anyone know what kind of an object stats_ver_current is?
> >
> > I'm also interesting in what it is that it's doing. In the comment it says
> > like this, but I'm not sure what it means.
> >
> > -- also, force a refresh if the stats blob version is not current
> >
> > Ola Hallengren
> > http://blog.ola.hallengren.com
>
>

> Is there a way to fool SQL Server into thinking that it is executing in the
> context of a system procedure, thus making it possible to use these
> not-for-peon functions?
>
> Linchi

"Aaron Bertrand [SQL Server MVP]" wrote:

> I don't know of any way to do so, no.  It is certainly not as simple as
> marking your procedure as a system object.
>
> PS you can look at *some* internal functions by shutting down SQL Server,
> copying the resource mdf/ldf files, and then attaching them as a different
> name and in a different path.  You still won't be able to execute them, of
> course.
>
>
>
>
> On 6/24/09 5:23 PM, in article
> A1FD5429-E586-41E2-8A89-15BE0653D***@microsoft.com, "Linchi Shea"
> <LinchiS***@discussions.microsoft.com> wrote:
>
> > Is there a way to fool SQL Server into thinking that it is executing in the
> > context of a system procedure, thus making it possible to use these
> > not-for-peon functions?
> >
> > Linchi
>
>

"Ola Hallengren" <OlaHalleng***@discussions.microsoft.com> wrote in
message news:3884F96D-DB84-4022-AD0A-F23EEF3C1249@microsoft.com...
> I'm trying to understand this code from sp_updatestats. If any rows
> has
> changed since the statistics was last updated or ...
> Are they checking if the statistics has been created with another
> sql server
> build than the current one (and in that case update the statistics
> even if no
> rows has changed)?
>
> declare @is_ver_current bit
> select @is_ver_current = stats_ver_current(@table_id, @ind_id)
>
> -- note that <> 0 should work against old and new rowmodctr logic
> (when it
> is always > 0)
> -- also, force a refresh if the stats blob version is not current
> if ((@ind_rowmodctr <> 0) or ((@is_ver_current is not null) and
> (@is_ver_current = 0)))
>
> Ola Hallengren
> http://blog.ola.hallengren.com
>
>
>
> "Aaron Bertrand [SQL Server MVP]" wrote:
>
>> I don't know of any way to do so, no.  It is certainly not as
>> simple as
>> marking your procedure as a system object.
>>
>> PS you can look at *some* internal functions by shutting down SQL
>> Server,
>> copying the resource mdf/ldf files, and then attaching them as a
>> different
>> name and in a different path.  You still won't be able to execute
>> them, of
>> course.
>>
>>
>>
>>
>> On 6/24/09 5:23 PM, in article
>> A1FD5429-E586-41E2-8A89-15BE0653D***@microsoft.com, "Linchi Shea"
>> <LinchiS***@discussions.microsoft.com> wrote:
>>
>> > Is there a way to fool SQL Server into thinking that it is
>> > executing in the
>> > context of a system procedure, thus making it possible to use
>> > these
>> > not-for-peon functions?
>> >
>> > Linchi
>>
>>

"Tibor Karaszi" wrote:

> Hi Ola,
>
> My guess is that it check for statistics for older versions. But that
> is only a guess. Why not give it a try. If you have, say, a 2000
> instance, you can just create a database, table populate, update stats
> (so nothing is stale) and see whether this will update the stats. By
> comparing to a couple of alternatives for a non-upgraded databases,
> you should have more to go one... :-)
>
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
>
> "Ola Hallengren" <OlaHalleng***@discussions.microsoft.com> wrote in
> message news:3884F96D-DB84-4022-AD0A-F23EEF3C1249@microsoft.com...
> > I'm trying to understand this code from sp_updatestats. If any rows
> > has
> > changed since the statistics was last updated or ...
> > Are they checking if the statistics has been created with another
> > sql server
> > build than the current one (and in that case update the statistics
> > even if no
> > rows has changed)?
> >
> > declare @is_ver_current bit
> > select @is_ver_current = stats_ver_current(@table_id, @ind_id)
> >
> > -- note that <> 0 should work against old and new rowmodctr logic
> > (when it
> > is always > 0)
> > -- also, force a refresh if the stats blob version is not current
> > if ((@ind_rowmodctr <> 0) or ((@is_ver_current is not null) and
> > (@is_ver_current = 0)))
> >
> > Ola Hallengren
> > http://blog.ola.hallengren.com
> >
> >
> >
> > "Aaron Bertrand [SQL Server MVP]" wrote:
> >
> >> I don't know of any way to do so, no.  It is certainly not as
> >> simple as
> >> marking your procedure as a system object.
> >>
> >> PS you can look at *some* internal functions by shutting down SQL
> >> Server,
> >> copying the resource mdf/ldf files, and then attaching them as a
> >> different
> >> name and in a different path.  You still won't be able to execute
> >> them, of
> >> course.
> >>
> >>
> >>
> >>
> >> On 6/24/09 5:23 PM, in article
> >> A1FD5429-E586-41E2-8A89-15BE0653D***@microsoft.com, "Linchi Shea"
> >> <LinchiS***@discussions.microsoft.com> wrote:
> >>
> >> > Is there a way to fool SQL Server into thinking that it is
> >> > executing in the
> >> > context of a system procedure, thus making it possible to use
> >> > these
> >> > not-for-peon functions?
> >> >
> >> > Linchi
> >>
> >>
>
>