Re^2: fetchall_arrayref hangs with placeholders query with no results

I like your idea of having a tablename. I've never used a DB where there is some default table with no name. I do know that prepare statements are table specific (i.e. the table name cannot be from a placeholder). I see from the thread that this Sybase thing does something weird during the prepare, I am wondering if not having a table name somehow causes some confusion in the temporary stored procedure in the error case of "no results"?

While experimenting, I would also try without the hashref part, instead of $sth->fetchall_arrayref({}); use just $sth->fetchall_arrayref(); Asking for a less complicated data structure maybe makes a difference?

Comment on Re^2: fetchall_arrayref hangs with placeholders query with no results Select or Download Code

Replies are listed 'Best First'.
Re^3: fetchall_arrayref hangs with placeholders query with no results by TieUpYourCamel (Scribe) on Apr 21, 2021 at 16:20 UTC
Thanks for your suggestion. Unfortunately not passing the hashref produces the same results.	[reply]
Re^4: fetchall_arrayref hangs with placeholders query with no results by Marshall (Canon) on Apr 23, 2021 at 00:25 UTC
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.	[reply]