FreeTDS Development Group

[Garrett Goebel <garrett AT scriptpro.com>]

ZIGLIO Frediano wrote:
> > 
> > 1) If I create a stored procedure:
> > 
> >   create procedure odbc_call as return 1
> > 
> > and a perl script:
> > 
> > #!usr/bin/perl -w
> > use DBI;
> > my $rv = 0;
> > my $dbh = DBI->connect(
> >     'dbi:ODBC:ServerName=RD_Q;Driver=TDS;Database=SPCentral',
> >     'sa', 'mypasswd',
> >     {RaiseError => 1, AutoCommit => 1}
> > ) or die DBI->errstr;
> > $dbh->trace(1);
> > my $sth = $dbh->prepare('{ ? = call odbc_call() }');
> 
> Syntax is wrong, use {?=call odbc_call()}. Documentation say 
> nothing about space...

>From SQL Server Books Online (MSSQL7.0):
> How to call a stored procedure (ODBC)
[...]
> {? = CALL procname (?,?)} 

>From which I'll guess I won't be the only person to report problems due to
questionably optional whitespace...


> > 
> > 2) If I alter the prepared statement to remove all 
> > unnecessary whitespace:
> > 
> >   {?=call odbc_call()}
> > 
> > I get a segmentation fault. The segfault goes away if I:
> > o  place a space between the opening '{' and '?'
> >    { ?=call odbc_call()}
> > o  alter the stored proc to return a result set
> >    create procedure odbc_call as select 1 return 1
> >
> ...
> 
> I'll look deepeer..

I should have been more specific. The segfault goes away if I do either of
the two things I mentioned. I.e., that's an OR not an AND. So the
reproduction case for the segfault is to use the odbc call escape sequence
on a stored procedure that returns no result set.

Let me know if I can provide any more information that would be useful.

thanks,

Garrett

--
Garrett Goebel
IS Development Specialist

ScriptPro                  Direct: 913.403.5261
5828 Reeds Road            Main:   913.384.1008
Mission, KS 66202          Fax:    913.384.2180
www.scriptpro.com          garrett at scriptpro dot com