Ran across this sql the other day.
-
USE [Database1]
GO
/****** Object: StoredProcedure [dbo].[CheckConnection] Script Date: 08/14/2008 10:54:38 ******/
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
-- Validate User can hit the sql box. Basically doesn't do anything, except ensure I can see the sql box
-- Returns 1 if successful,
-- 0 l if failed (one could ask, If I can't see the box, how is it going to return 0....I don't know).
-- 3/26/04 (via name omitted)
-- Assumes SQL Server 7.0 SP1 or better
ALTER procedure [dbo].[CheckConnection]
@result char(1) OUTPUT
AS
set @result = "1"
RETURN:laugh:
-
USE [Database1]
GO
/****** Object: StoredProcedure [dbo].[CheckConnection] Script Date: 08/14/2008 10:54:38 ******/
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
-- Validate User can hit the sql box. Basically doesn't do anything, except ensure I can see the sql box
-- Returns 1 if successful,
-- 0 l if failed (one could ask, If I can't see the box, how is it going to return 0....I don't know).
-- 3/26/04 (via name omitted)
-- Assumes SQL Server 7.0 SP1 or better
ALTER procedure [dbo].[CheckConnection]
@result char(1) OUTPUT
AS
set @result = "1"
RETURN:laugh:
:omg: Hokay. So you can't just test the state of the connection then...
Deja View - the feeling that you've seen this post before.
-
USE [Database1]
GO
/****** Object: StoredProcedure [dbo].[CheckConnection] Script Date: 08/14/2008 10:54:38 ******/
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
-- Validate User can hit the sql box. Basically doesn't do anything, except ensure I can see the sql box
-- Returns 1 if successful,
-- 0 l if failed (one could ask, If I can't see the box, how is it going to return 0....I don't know).
-- 3/26/04 (via name omitted)
-- Assumes SQL Server 7.0 SP1 or better
ALTER procedure [dbo].[CheckConnection]
@result char(1) OUTPUT
AS
set @result = "1"
RETURN:laugh:
:laugh:
Austin Harris wrote:
If I can't see the box, how is it going to return 0....I don't know
:laugh:
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
:omg: Hokay. So you can't just test the state of the connection then...
Deja View - the feeling that you've seen this post before.
No of course not... security and permissions you know. :-D
-
USE [Database1]
GO
/****** Object: StoredProcedure [dbo].[CheckConnection] Script Date: 08/14/2008 10:54:38 ******/
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
-- Validate User can hit the sql box. Basically doesn't do anything, except ensure I can see the sql box
-- Returns 1 if successful,
-- 0 l if failed (one could ask, If I can't see the box, how is it going to return 0....I don't know).
-- 3/26/04 (via name omitted)
-- Assumes SQL Server 7.0 SP1 or better
ALTER procedure [dbo].[CheckConnection]
@result char(1) OUTPUT
AS
set @result = "1"
RETURN:laugh:
:laugh::laugh::laugh:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
USE [Database1]
GO
/****** Object: StoredProcedure [dbo].[CheckConnection] Script Date: 08/14/2008 10:54:38 ******/
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
-- Validate User can hit the sql box. Basically doesn't do anything, except ensure I can see the sql box
-- Returns 1 if successful,
-- 0 l if failed (one could ask, If I can't see the box, how is it going to return 0....I don't know).
-- 3/26/04 (via name omitted)
-- Assumes SQL Server 7.0 SP1 or better
ALTER procedure [dbo].[CheckConnection]
@result char(1) OUTPUT
AS
set @result = "1"
RETURN:laugh:
-
USE [Database1]
GO
/****** Object: StoredProcedure [dbo].[CheckConnection] Script Date: 08/14/2008 10:54:38 ******/
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
-- Validate User can hit the sql box. Basically doesn't do anything, except ensure I can see the sql box
-- Returns 1 if successful,
-- 0 l if failed (one could ask, If I can't see the box, how is it going to return 0....I don't know).
-- 3/26/04 (via name omitted)
-- Assumes SQL Server 7.0 SP1 or better
ALTER procedure [dbo].[CheckConnection]
@result char(1) OUTPUT
AS
set @result = "1"
RETURN:laugh:
We used to have a standard stored procedure that did that. I pointed out that a successful 'ping' didn't mean anything at all: the server could be down or the connection lost by the time that the next call was made. It's been phased out. Someone did claim that there was a problem with some old version of ADO that wouldn't return the results of the first stored procedure call you made after connecting, and so you called a dummy procedure before what you actually wanted to do. I'm skeptical - I've never seen a bug report on that. It smells of cargo-cult programming, and of the worst kind: chinese-whispers cargo-cult programming, where the implementor has heard that there's a problem and has heard that this will fix it, but has not experienced the problem themselves.
DoEvents: Generating unexpected recursion since 1991