FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

On Wed, 20 Nov 2002 16:50:42 -0500, "Castellano, Nicholas"
<Nicholas_Castellano AT acml.com> wrote:
> I think we should just scrap src/dblib/unittests/t0022.c.  It seems to
> be the general consensus that this is obsolete functionality and just
> isn't useful behavior anyway.  

Nick, 

I really should never answer things when I'm rushing out the door.  I
think I know what you're going after, now, having re-read the thread.  

What you're saying is:

        sprintf(cmd, "declare @b int\nexec t0022 @b = @b output\n");
        fprintf(stdout, "%s\n", cmd);
        dbcmd(dbproc, cmd);

isn't supported (per Bill [thanks Bill!]) on a Microsoft server anymore,
so let's can it.  

The demarcation point, as you guessed and as Bill said, is SQL server 7
service pack 3. 

It would be nice to have the test work for those servers it should work
on, in the way they expect to be used.  

It's an old bugaboo of ours that we can't discover the service
pack/whatever level through the API; we have to parse the version string. 
Brian used to do that for "broken datetimes" until he just gave up and
emulated little endian throughout.  I've complained to Steve Balmer about
this.  Well, actually I haven't, but the effect is the same.  

I think it would be satisfactory if t0022.c remained as is with an
advisory message indicating that failure is normal for Microsoft servers
"SQL Server 7.0 service pack 3" and above.  Or, as they say in traffic
court, "Guilty with an explanation."  

If the TDS version is 8+, we *know* it won't work, shouldn't try, and
shouldn't fail.  

If the TDS version is 7 or 8, we can set the procedure name to #t0022,
obviating the permissions problem.  

Now I'm going to look at Bob's dump.  Does any of the aforegoing sound
reasonable to you?

--jkl