when i run activex Script it's shows this error
[ActiveX Script Task] Error: Retrieving the file name for a component failed with error code 0x001B6438
when i run activex Script it's shows this error
[ActiveX Script Task] Error: Retrieving the file name for a component failed with error code 0x001B6438
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.
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
I have a page that connects to SQL server. It works fine when running in local host but when I publish to the server, I get the following:
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
Any ideas on where to start?
Thanks,
Mark
Try these two blog posts:
http://blogs.msdn.com/sql_protocols/archive/2005/10/22/483684.aspx
http://blogs.msdn.com/sql_protocols/archive/2005/10/29/486861.aspx
When I attempt to update using a stored procedure I get the error 'Incorrect syntax near sp_upd_Track_1'. The stored procedure looks like the following when modified in SQLServer:
ALTERPROCEDURE [dbo].[sp_upd_CDTrack_1]
(@.CDTrackNamenvarchar(50),
@.CDArtistKeysmallint,
@.CDTitleKeysmallint,
@.CDTrackKeysmallint)
AS
BEGIN
SETNOCOUNTON;
UPDATE [Demo1].[dbo].[CDTrack]
SET [CDTrack].[CDTrackName]= @.CDTrackName
WHERE [CDTrack].[CDArtistKey]= @.CDArtistKey
AND [CDTrack].[CDTitleKey]= @.CDTitleKey
AND [CDTrack].[CDTrackKey]= @.CDTrackKey
END
But when I use the following SQL coded in the gridview updatecommand it works:
"UPDATE [Demo1].[dbo].[CDTrack]
SET [CDTrack].[CDTrackName] = @.CDTrackName
WHERE [CDTrack].[CDArtistKey] = @.CDArtistKey
AND [CDTrack].[CDTitleKey] = @.CDTitleKey
AND [CDTrack].[CDTrackKey] = @.CDTrackKey"
Whats the difference? The storedproc executes ok in sql server and I guess that as the SQL version works all of my databinds are correct. Any ideas, thanks, James.
Not sure if it's the source of your problem, but shouldn't sp_upd_Track_1 and p_upd_CDTrack_1 be the same or was that a typo?
|||Yeah, typo, the correct name is specified in the storedproc and referenced correctly in the asp.