Extended properties created by Visual Studio on CLR UDF''s

When one deploys a CLR DLL that contains [SqlFunction]'s, Visual Studio creates three extended properties on the SQL function that is created: these are,

AutoDeployed, SqlAssemblyFile, SqlAssemblyFileLine.

What I haven't found anywhere on Help or MSDN online is what these extended properties mean.

Could someone enlighten me?

1. What is a description of the above properties?

2. What is the benefit of using them (clearly the function works without using them). Does it help debugging?

3. Does the developer need to manually keep for instance the SqlAssemblyFileLine in sync with changes in the .NET code?

Thanks a lot.

Aneela_B wrote:

When one deploys a CLR DLL that contains [SqlFunction]'s, Visual Studio creates three extended properties on the SQL function that is created: these are,

AutoDeployed, SqlAssemblyFile, SqlAssemblyFileLine.

What I haven't found anywhere on Help or MSDN online is what these extended properties mean.

Could someone enlighten me?

1. What is a description of the above properties?

2. What is the benefit of using them (clearly the function works without using them). Does it help debugging?

3. Does the developer need to manually keep for instance the SqlAssemblyFileLine in sync with changes in the .NET code?

AFAIK, the above properties do not have any use at the moment. They have no impact on debugging.

If you change the .NET code you have to re-deploy your assembly (either CREATE or ALTER).

Niels

Extended properties created by Visual Studio on CLR UDF''s

When one deploys a CLR DLL that contains [SqlFunction]'s, Visual Studio creates three extended properties on the SQL function that is created: these are,

AutoDeployed, SqlAssemblyFile, SqlAssemblyFileLine.

What I haven't found anywhere on Help or MSDN online is what these extended properties mean.

Could someone enlighten me?

1. What is a description of the above properties?

2. What is the benefit of using them (clearly the function works without using them). Does it help debugging?

3. Does the developer need to manually keep for instance the SqlAssemblyFileLine in sync with changes in the .NET code?

Thanks a lot.

Aneela_B wrote:

When one deploys a CLR DLL that contains [SqlFunction]'s, Visual Studio creates three extended properties on the SQL function that is created: these are,

AutoDeployed, SqlAssemblyFile, SqlAssemblyFileLine.

What I haven't found anywhere on Help or MSDN online is what these extended properties mean.

Could someone enlighten me?

1. What is a description of the above properties?

2. What is the benefit of using them (clearly the function works without using them). Does it help debugging?

3. Does the developer need to manually keep for instance the SqlAssemblyFileLine in sync with changes in the .NET code?

AFAIK, the above properties do not have any use at the moment. They have no impact on debugging.

If you change the .NET code you have to re-deploy your assembly (either CREATE or ALTER).

Niels

Ext. SPs

I need to be able to create my own MSSQ UDF to return the current system
date, offset by a configurable number of minutes, depending on a value in a
table. The reason I am trying to do this is, I want to be able to, for
testing purposes, fake the system into thinking that time has elapsed.
Changing the time on the computer is not an option.

I would like to call the UDF MyGetDate and to replace all code occurrence of
getdate() in the database with this call. This includes column default value
constraints and stored procedures.

The problem is that MSSQL does not allow the function GETDATE with a UDF. I
thought to try an fake it out by having the UDF call a SP, which in turn
called GETDATE. When I did this, I got the error 'Only functions and
extended stored procedures can be executed from within a function.'

I guess I can go down the road to try and learn how to write an extended
stored procedure to return the current time, but I imagine that there is a
learning curve here.

I realize that all COLUMN default CONSTRAINT with GETDATE could be handled
by create ADD AND UPDATE TRIGGERS that populate thisIt's a kludge but you can create a UDF that reads a value from a table.
Then schedule a Sql Agent Job to run every minute, updating that
table's value.|||Chad (chad.dokmanovich@.unisys.com) writes:
> I need to be able to create my own MSSQ UDF to return the current system
> date, offset by a configurable number of minutes, depending on a value
> in a table. The reason I am trying to do this is, I want to be able to,
> for testing purposes, fake the system into thinking that time has
> elapsed. Changing the time on the computer is not an option.
> I would like to call the UDF MyGetDate and to replace all code
> occurrence of getdate() in the database with this call. This includes
> column default value constraints and stored procedures.
> The problem is that MSSQL does not allow the function GETDATE with a
> UDF. I thought to try an fake it out by having the UDF call a SP, which
> in turn called GETDATE. When I did this, I got the error 'Only functions
> and extended stored procedures can be executed from within a function.'
> I guess I can go down the road to try and learn how to write an extended
> stored procedure to return the current time, but I imagine that there is a
> learning curve here.

Using a UDF in all sorts of constraints, could have performance issues,
and if that UDF calls an extended procedure that does not make things
better.

You could save the show with:

CREATE FUNCTION kalle(@.d datetime) RETURNS datetime AS
BEGIN
RETURN dateadd(DAY, 12, @.d)
END
go
select dbo.kalle(getdate())

Yes, that will be somewhat bulkier, but it should get the job one.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp