http://qs321.pair.com?node_id=558235

santhi has asked for the wisdom of the Perl Monks concerning the following question:

Hi Perl Monks,

I am using latest version of DBD::Sybase on SUN-OS-4.0
When using placeholders("?") to execute the queries in the DBI prepare statement and passing the values in the DBI execute statement, error messages are displayed.
for example:
DBI->trace(15); $sth= $dbh->prepare("update sample set name =? where sno = '123a'"); $sth->execute('example');

I have used DBI->trace(15), to trace the error.
DBI 1.51-nothread default trace level set to 0x0/15 (pid 18749)
sql is UPDATE EstWebquote set comments = ? where filename ='a'
prepare DISPATCH (DBI::db=HASH(0x2f7c24) rc1/1 @2 g0 ima2201 pid#1 +8749) at testsql.pl line 111 -> prepare for DBD::Sybase::db (DBI::db=HASH(0x2f7c24)~0x1e3e64 'UPDAT +E sample set name = ? where sno ='123a'') New DBI::st (for DBD::Sybase::st, parent=DBI::db=HASH(0x1e3e64), i +d=) dbih_setup_handle(DBI::st=HASH(0x1e4194)=>DBI::st=HASH(0x1e4134), +DBD::Sybase::st, 1e41a0, Null!) dbih_make_com(DBI::db=HASH(0x1e3e64), 3097e8, DBD::Sybase::st, 420 +, 0) thr#0 dbih_setup_attrib(DBI::st=HASH(0x1e4134), Err, DBI::db=HASH(0x1e3e +64)) SCALAR(0x283d40) (already defined) dbih_setup_attrib(DBI::st=HASH(0x1e4134), State, DBI::db=HASH(0x1e +3e64)) SCALAR(0x283da0) (already defined) dbih_setup_attrib(DBI::st=HASH(0x1e4134), Errstr, DBI::db=HASH(0x1 +e3e64)) SCALAR(0x283d70) (already defined) dbih_setup_attrib(DBI::st=HASH(0x1e4134), TraceLevel, DBI::db=HASH +(0x1e3e64)) 0 (already defined) dbih_setup_attrib(DBI::st=HASH(0x1e4134), FetchHashKeyName, DBI::d +b=HASH(0x1e3e64)) 'NAME' (already defined) dbih_setup_attrib(DBI::st=HASH(0x1e4134), HandleSetErr, <br>DBI::d +b=HASH(0x1e3e64)) undef (not defined) dbih_setup_attrib(DBI::st=HASH(0x1e4134), HandleError, <br>DBI::db +=HASH(0x1e3e64)) undef (not defined) syb_st_prepare() -> inUse = 0 dbd_preparse parameter :p1 () dbd_preparse scanned 1 distinct placeholders dyn_prepare: ct_dynamic(CS_PREPARE) for DBD1 syb_alloc_cmd() -> CS_COMMAND 30b3a0 for CS_CONNECTION 135260 ct_send(CS_DESCRIBE_INPUT) returned 0 at /usr/local/lib/perl5/site_per +l/5.8.7/sun4-solaris/DBD/Sybase.pm line 133. dyn_prepare: ct_dynamic(CS_DESCRIBE_INPUT) for DBD1 dyn_prepare: ct_results(CS_DESCRIBE_INPUT) for DBD1 - restype 4051 Segmentation Fault (core dumped)


Can anyone please help me how to resolve this?
Thanks,
Santhi

20060629 Janitored by Corion: Added more code tags, as per Writeup Formatting Tips

2006-06-30 Retitled by Arunbear
Original title: 'Problem with use of Palceholders(?) in the prepare statements for executing the queries of Sybase (DBD::Sybase)'

Replies are listed 'Best First'.
Re: Placeholders(?) in the prepare statements for executing DBD::Sybase queries
by McDarren (Abbot) on Jun 29, 2006 at 07:38 UTC
    From the DBD::Sybase docs:
    DBD::Sybase supports the use of ? placeholders in SQL statements as lo +ng as the underlying library and database engine supports it.

    So it's possible that the database engine you are using does not support placeholders. Certainly, I know this is the case with FreeTDS, as documented here.

    If this is the problem in your case, then the solution would probably be to switch to ODBC.

    Hope this helps,
    Darren :)

      I know this thread is very old, but the following information might be beneficial to occasional lurkers: I was able to run SELECT and UPDATE queries with placeholders with DBD::Sybase (version 1.15) connecting to SQL Server through FreeTDS (version 0.91). $db->{syb_dynamic_supported} returns 1.
      لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re: Placeholders(?) in the prepare statements for executing DBD::Sybase queries
by VSarkiss (Monsignor) on Jun 29, 2006 at 13:59 UTC
      Actually, this bit
      syb_alloc_cmd() -> CS_COMMAND 30b3a0 for CS_CONNECTION 135260 ct_send(CS_DESCRIBE_INPUT) returned 0 at /usr/local/lib/perl5/site_per +l/5.8.7/sun4-solaris/DBD/Sybase.pm line 133.
      is the clue that the OP is using FreeTDS.

      And yes, that is the reason why the placeholders don't work (yet).

      Michael

A reply falls below the community's threshold of quality. You may see it by logging in.