How can lock my database if any user stole my mdf and ldf file,User not able to attach the file.

Thanks
Mayank…………….

create VIEW vRand
AS
SELECT RAND() AS ‘number’
GO

create VIEW vRand
AS
SELECT RAND() AS ‘number’
GO

Create Table summa (Samp Text)

insert into summa values(‘Hai’)
Insert into summa values(‘Buddy’)

select TextPtr(Samp)from summa

declare @txtpt Binary(16)
Select @txtpt=TextPtr(Samp)from summa
ReadText summa.Samp @txtpt 0 5

I know there’s a few workarounds, such as having the RAND in a view, or just using a stored proc instead, but it’s a real pain. Just can’t understand the logic of banning the RAND function from within a UDF!

Someone as M$ is taking the whole “no side-effects” thing a bit too literally. At least this is a step in the right direction.

You still cannot use
NEWID
RAND
NEWSEQUENTIALID and
TEXTPTR

I got that detail from SQL Server Magazine, and may have changed since publication, but the end result is – it is not a bug, you can use GETDATE() in functions,

Here is more directly from the article

“SQL Server 2005 Books Online (BOL) doesn’t provide a reason for this change or the distinction between the functions that are and aren’t allowed, but you’ll notice that the functions you can’t use have side effects. That is, the SQL Server 2005 non-deterministic functions that aren’t allowed make internal changes in the database or the system and leave a mark (such as a change to an interval value) that they have been invoked. And UDFs aren’t allowed to have side effects. For example, when SQL Server invokes the RAND function it changes an internal value that’s used to calculate the seed for the next invocation of the function. This means that had SQL Server allowed you to invoke RAND within a UDF, the invocation of the UDF would have changed the result of subsequent invocations of RAND outside the UDF as well. For this reason, you can’t use RAND in a UDF, even in SQL Server 2005.”