Call a function without used dbo prefix

Hi all,
do you know if is it possible to call a function without the dbo prefix :
select dbo.myfunction : works fine
select myfunction : return an error message 'myfunction is not a recognize
function'
I've searched on permission right but unsuccessffuly ...
Thank's for your help.
Nicolas.
On Wed, 15 Dec 2004 07:59:08 -0800, Nicolas Fortier <Nicolas
Fortier@.discussions.microsoft.com> wrote:

>Hi all,
>do you know if is it possible to call a function without the dbo prefix :
>select dbo.myfunction : works fine
>select myfunction : return an error message 'myfunction is not a recognize
>function'
>I've searched on permission right but unsuccessffuly ...
>Thank's for your help.
>Nicolas.
>
Hi Nicolas,
This is not possible. You must always include the owner of a userdefined
function.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||"Hugo Kornelis" wrote:

> On Wed, 15 Dec 2004 07:59:08 -0800, Nicolas Fortier <Nicolas
> Fortier@.discussions.microsoft.com> wrote:
>
> Hi Nicolas,
> This is not possible. You must always include the owner of a userdefined
> function.
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)
>
Hugo, thank's for your answer.
BR
Nicolas.
|||"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:udo0s09hg55fna924ja8pavss40nqkekj1@.4ax.com...

> You must always include the owner of a userdefined function.
Just out of curiosity, have you ever heard of a rationale for this? Seems
weird you don't have to include the owner of a stored procedure, but you do
have to include it for a UDF.
|||Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.server:373253
On Wed, 15 Dec 2004 10:53:13 -0800, Mark Wilden wrote:

>"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
>news:udo0s09hg55fna924ja8pavss40nqkekj1@.4ax.com.. .
>
>Just out of curiosity, have you ever heard of a rationale for this? Seems
>weird you don't have to include the owner of a stored procedure, but you do
>have to include it for a UDF.
>
Hi Mark,
No, never. If I have to take a guess, I'd say it was to limit the
complexity of parsing the SQL.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||"Mark Wilden" <mark@.mwilden.com> wrote in message
news:iOydnelPJfeqFV3cRVn-ow@.sti.net...
> "Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
> news:udo0s09hg55fna924ja8pavss40nqkekj1@.4ax.com...
>
> Just out of curiosity, have you ever heard of a rationale for this? Seems
> weird you don't have to include the owner of a stored procedure, but you
do
> have to include it for a UDF.
>
Probably performance.
While you don't need to do it for stored procs, it's generally a good idea.

>
|||To distinguish between user-defined functions and system functions.
e.g. imagine if you have a function called error_message(), then you upgrade
your database to Yukon and your application is getting invalid values over
the place.
If you have to use a prefix, there's no chance of the engine trying to tell
the difference...
"Mark Wilden" <mark@.mwilden.com> wrote in message
news:iOydnelPJfeqFV3cRVn-ow@.sti.net...
> "Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
> news:udo0s09hg55fna924ja8pavss40nqkekj1@.4ax.com...
>
> Just out of curiosity, have you ever heard of a rationale for this? Seems
> weird you don't have to include the owner of a stored procedure, but you
do
> have to include it for a UDF.
>
|||"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:uD%23oq6x4EHA.1596@.tk2msftngp13.phx.gbl...
> To distinguish between user-defined functions and system functions.
>
This doesn't really answer the question though.
What if you had a stored proc called error_message and then upgrade the
database to Yukon and your application is now calling the wrong stored proc
all over the place. :-)
(I think you're probably right, this has something to do with it, but why
wasn't this done for stored procs?)

> e.g. imagine if you have a function called error_message(), then you
upgrade
> your database to Yukon and your application is getting invalid values over
> the place.
> If you have to use a prefix, there's no chance of the engine trying to
tell[vbcol=seagreen]
> the difference...
>
> "Mark Wilden" <mark@.mwilden.com> wrote in message
> news:iOydnelPJfeqFV3cRVn-ow@.sti.net...
Seems
> do
>
|||Hi All,
to solve my initial problem, is it possible to create a synonym (like with
oracle) to doesn't use the owner in a call fucntion ?
"Greg D. Moore (Strider)" wrote:

> "Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
> news:uD%23oq6x4EHA.1596@.tk2msftngp13.phx.gbl...
> This doesn't really answer the question though.
> What if you had a stored proc called error_message and then upgrade the
> database to Yukon and your application is now calling the wrong stored proc
> all over the place. :-)
> (I think you're probably right, this has something to do with it, but why
> wasn't this done for stored procs?)
>
> upgrade
> tell
> Seems
>
>
|||> What if you had a stored proc called error_message and then upgrade the
> database to Yukon and your application is now calling the wrong stored
proc
> all over the place. :-)
Well, system stored procedures are prefixed with sp_, and the documentation
clearly advises against using the same naming scheme for user-defined
procedures. So I think their bases are covered there.
It probably would have been better if a similar tack was taken with
functions, e.g. fn_ for system functions, and find your own naming scheme
for your own. (Though many of the built-in functions were created without
any specific naming scheme, long before UDFs were introduced. And there
would have been a lot of backlash if people had to go back and change
DB_NAME() to fn_DBNAME(), for example.)
If there are other reasons than those already brought up in this thread, I'm
not aware of them. I could make stuff up, but in either case, it's not
going to do you any good because the implementation is not going to
change...
A