Thank you. Where is your blog?

Thanks. Both the methods working fine. I am updating as many as I get in this range. The others would be still a challenge

The val is actually a binary value. So I tried doing the below as per your suggestion.

declare @varBin as varbinary(max)

set @varBin = 0x06E3231322020202020203737363533313231322020202020203737323137364D616E756661637475726573206F66206361726275726574746F727320616E6420706172747320666F722074776F2026207468726565A

SELECT convert(varbinary(max),STUFF(@varBin,3,1,''))

--Result

0x06E31322020202020203737363533313231322020202020203737323137364D616E756661637475726573206F66206361726275726574746F727320616E6420706172747320666F722074776F2026207468726565A

If I try to remove leading zero from 0x0231 with

STUFF(column_name,1,1,'') then it removes 02 as that is the first character in binary and makes the binary pattern as 0x31 instead...

Thanks for the reply. The datatype of the column is varchar(255) where junk characters are seen.

if we convert that to varbinary(max) in select statement we get the pattern

The error is resolved. I had to set "DisableLoopBackcheck" parameter value in the registry for the server.

It was local system account. I have set it to windows domain account. But still the error is unchanged.

It is actually a new line character which is not getting printed on the forum.

Actually nobody did the restore manually but the server was restarted once by the infra team...really not sure what has caused these entries in the error logs.

To let you know there are few entries in SQL Server error log on 28th as

2011-07-28 08:57:09.09 spid56 The database 'dbname' is marked RESTORING...

Yes you are right.

the command executed successfully without any error messages.

i.e. The data loss was report on 26th the data entry which is available in log is from 27th Onward.

Not exactly the drive error but windows error log on 26...

I wonder why the data is lost from both the log file(as the log reader software does not show any log entry) and data file.

Please tell whether the following could...

Yeah.I tried with the user. It seems the user is right. The data which was entered in some other database on the same drive was also lost.When we checked the...