|
|
|
| Do you know where your variables are? | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
I was a afraid of that. I didn't have much hope that would work. I did have a lot more hope for using only
named tables. I hope that you tried that also?
This is truly a bizarre symptom! I mean it is not like we are testing some obscure, seldom used feature. A SELECT that returns no data is a completely normal thing to have happen! Geez, you can't claim to have a working DBI interface if you can't handle that! Sounds like something related to TDS level is likely to be the root cause: Sybase TDS Level I was wondering if there was a way to find out the number of rows that would be returned before asking for the array ref. But no luck. The execute method returns the number of rows affected or the string "0E0" (the "true" but numeric zero value). But that ONLY works for non-Select statements! (like ALTER or whatever). The only "super kludge" that I can think of is (a)don't use placeholders - which I guess you are doing now or (b) first run a select with (COUNT *) to get the row count and then re-run the select without the COUNT to get the data if count>0. Of course then your DB performance is now 1/2! That's nasty. Not using placeholders is also not so good because the prepare work has to be done again and again. Without a solution to the TDS level issue, I am afraid options are limited. In reply to Re^4: fetchall_arrayref hangs with placeholders query with no results
by Marshall
|
|