Showing posts with label library. Show all posts
Showing posts with label library. Show all posts

Tuesday, March 27, 2012

About @@ERROR in SQL 2005 online book

Here

http://msdn2.microsoft.com/en-us/library/ms190193.aspx

it is explained that @.@.ERROR will be cleared and reset.

But here:

http://msdn2.microsoft.com/en-us/library/ms190248.aspx

http://msdn2.microsoft.com/en-us/library/ms187009.aspx

we still see:

IF (@.@.ERROR <> 0)

SET @.ErrorSave = @.@.ERROR

Chester

Is there a question here?

I assume you are asking if @.@.Error is reset during the IF statement. If you read the first link, it says NO.

http://msdn2.microsoft.com/en-us/library/ms190193.aspx

@.@.Error is reset by the next TSQL command. IF is a conditional statement and does not reset the flag.|||

Hi Chester,

The second example is indeed incorrect as @.@.error will be reset to 0 by the IF statement. The local @.ErrorSave should be set after each statement and them compared:

declare @.a int, @.ErrorSave int;

set @.a = (1 / 0); -- divide by zero

set @.ErrorSave = @.@.ERROR;

if (@.ErrorSave <> 0)
begin
select @.ErrorSave AS [ErrorNumber]
end

Cheers,
Rob

|||

Hi Tom,

That's sort of incorrect - the IF will return TRUE when evaluating the statement "IF (@.@.EROR <> 0)", however @.@.ERROR is then reset by the successful completion of the evaluation:

declare @.a int, @.ErrorSave int;

set @.a = (1 / 0); -- divide by zero

if (@.@.error <> 0)
begin
select @.@.error AS [ErrorNumber] -- will return 0
end

Cheers,
Rob

|||

Here

http://msdn2.microsoft.com/en-us/library/ms190193.aspx

It says exactly:

Conditional statements, such as the IF statement, reset @.@.ERROR. If you reference @.@.ERROR in an IF statement, references to @.@.ERROR in the IF or ELSE blocks will not retrieve the @.@.ERROR information. In the following example, @.@.ERROR is reset by IF and does not return the error number when referenced in the PRINT statement.

|||

Thanks, Robert.

Actually I found this problem in one of our partner's application that was wriiten by a local Robert.

When I checked the online book, it was misleading at first .

Chester

|||Yep, you are right, my mistake.

@.@.Error is reset by the IF. The best thing to do is: SET @.errorcode = @.@.ERROR right after the command.

The @.@.Error traps so little errors, it is almost worthless. Most of the time the error in the command just terminates the stored proc and never gets to the error trap anyway, unless you use Try/Catch.

About @@ERROR in SQL 2005 online book

Here

http://msdn2.microsoft.com/en-us/library/ms190193.aspx

it is explained that @.@.ERROR will be cleared and reset.

But here:

http://msdn2.microsoft.com/en-us/library/ms190248.aspx

http://msdn2.microsoft.com/en-us/library/ms187009.aspx

we still see:

IF (@.@.ERROR <> 0)

SET @.ErrorSave = @.@.ERROR

Chester

Is there a question here?

I assume you are asking if @.@.Error is reset during the IF statement. If you read the first link, it says NO.

http://msdn2.microsoft.com/en-us/library/ms190193.aspx

@.@.Error is reset by the next TSQL command. IF is a conditional statement and does not reset the flag.|||

Hi Chester,

The second example is indeed incorrect as @.@.error will be reset to 0 by the IF statement. The local @.ErrorSave should be set after each statement and them compared:

declare @.a int, @.ErrorSave int;

set @.a = (1 / 0); -- divide by zero

set @.ErrorSave = @.@.ERROR;

if (@.ErrorSave <> 0)
begin
select @.ErrorSave AS [ErrorNumber]
end

Cheers,
Rob

|||

Hi Tom,

That's sort of incorrect - the IF will return TRUE when evaluating the statement "IF (@.@.EROR <> 0)", however @.@.ERROR is then reset by the successful completion of the evaluation:

declare @.a int, @.ErrorSave int;

set @.a = (1 / 0); -- divide by zero

if (@.@.error <> 0)
begin
select @.@.error AS [ErrorNumber] -- will return 0
end

Cheers,
Rob

|||

Here

http://msdn2.microsoft.com/en-us/library/ms190193.aspx

It says exactly:

Conditional statements, such as the IF statement, reset @.@.ERROR. If you reference @.@.ERROR in an IF statement, references to @.@.ERROR in the IF or ELSE blocks will not retrieve the @.@.ERROR information. In the following example, @.@.ERROR is reset by IF and does not return the error number when referenced in the PRINT statement.

|||

Thanks, Robert.

Actually I found this problem in one of our partner's application that was wriiten by a local Robert.

When I checked the online book, it was misleading at first .

Chester

|||Yep, you are right, my mistake.

@.@.Error is reset by the IF. The best thing to do is: SET @.errorcode = @.@.ERROR right after the command.

The @.@.Error traps so little errors, it is almost worthless. Most of the time the error in the command just terminates the stored proc and never gets to the error trap anyway, unless you use Try/Catch.sql

Thursday, February 9, 2012

a full-text search engine

Hi

I'm working on a digital Library project. Can anybody suggest a powerfulAsp.net full-text search engine Script or guide?

Thanks

Hi,

If you're using SQL Server as the database, I would suggest the Microsoft Full-Text Engine for SQL Server.

The Microsoft Full-Text Engine for SQL Server (MSFTESQL) service is a full-text indexing and search engine. The MSFTESQL engine is built on Microsoft Search (MSSearch) technology and is integrated into the Microsoft SQL Server 2005 Database Engine more tightly than ever.

Please check the following link for more information

http://msdn2.microsoft.com/en-us/library/ms142587.aspx

HTH. If this does not answer your question, please feel free to mark the post as Not Answered and reply. Thank you!

|||

Thanks for your reply,

I use SQL Server 2005 and I don't think Microsoft Full-Text Engine is suitable for me because I don't want my search engine search the files. All of our books will scan with OCR components and the full text of books will extract into a "NTEXT" field of the bank. I want a search engine for searching the "NTEXT" field efficiently.

Meanwhile I use a shared hosting plan on internet and can't use Administrator role for database.

Can you suggest any solution?

Thank you very much