I've been using FreeTDS and DBD::Sybase to talk to my MS SQL server.
Despite the frankenstein aspect of it, it has generally gone well until
recently after upgrading to FreeTDS .061 and DBD::Sybase 0.95 and then 1.0.
There are still a few kinks, but mostly that has to do with NULL and NULL
sets, for which using eval makes a liveable work-around. 

However, I came across a problem totally unrelated to NULL sets.  It's an
issue with insert statements.  I don't have problems with other insert
statements.  And, I've been over this one back and forth to figure out
what's going on.  

After all the hoohaw with the newer versions of FreeTDS and DBD::Sybase, I
backed everthing down to what I know works, that is FreeTDS 0.60 and
DBD::Sybase 0.94.  Same thing.  I can't remember if I did recent upgrade on
DBI itself (I'm running 1.35).

Basically, the $dbh->prepare is adding an extra ') at the end of my query if
I make the call from a CGI environment.  And before you get all excited,
yes, I have done a number of interesting checks.  If I use the same package
from the command line, all is well.  If I generate the query as output
before the $sth->execute call, all is well.  If I generate the query out to
a text file, and paste it into the SQL Enterprise Manager's query tool, all
is well.

However, an interesting thing showed up in trace (3):

  The query generated to a temporary text file (from the CGI) or to browser
screen is output as:

        insert into plan_features
(plan_id,service_id,tier1_type,tier1_passage,tier2_type,tier3_type) values
('4','2','0','1','0','0')


    But in the log files (in debug mode on Apache) I'm seeing:

-> prepare for DBD::Sybase::db (DBI::db=HASH(0x8b4bec0)~0x8b00874 'insert
into plan_features
(plan_id,service_id,tier1_type,tier1_passage,tier2_type,tier3_type) values
('4','2','.0','1','.0','.0')')

   Which is OK, but I'm not sure where it's picking up the ".0".  I'm using
dbh->quote on all my vars.  But the query that is output before the execute
doesn't use the '.0', it only shows up as '0'.  Also, there are three float
fields in the table, but these aren't the ones.  I'm thinking about running
a test on a table without floats and seeing if this issue goes away, but I
do need the floats!  But later on it gets weirder...

       -> execute for DBD::Sybase::st (DBI::st=HASH(0x8b4f9a8)~0x8b4fa44)
    syb_st_execute() -> ct_command() OK
    syb_st_execute() -> ct_send() OK
    st_next_result() -> ct_results(13) == 1
    st_next_result() -> ct_results(12) == 1
ct_results() final retcode = 15
    st_next_result() -> lasterr = 170, lastsev = 15
    st_next_result() -> restype is not data result, force failFlag
    syb_st_execute() -> got CS_CMD_DONE: resetting ACTIVE, moreResults,
dyn_execed
    !! ERROR: 170 'Server message number=105 severity=15 state=1 line=1
server=SOMEDBSRV text=Unclosed quotation mark before the character string
''.Server message number=170 severity=15 state=1 line=1 server=SOMEDBSRV
text=Line 1: Incorrect syntax near ''.'

  Does anybody see '' in the output query above?  or in the traced prepare
statement?  I've just about gone around the bend trying to figure this one
out.

TIA!
Karyn

Reply via email to